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DESCRIPTION  AND  THEORETICAL  ANALYSIS  (USING  SCHEMATA)  OF 

PLANNER: 

A  LANGUAGE  FOR  PROVING  THEOREMS  AND 
MANIPULATING  MODELS  IN  A  ROBOT* 

Abstract 

PLANNER  is  a  formalism  for  proving  theorems  and  manipulating  models 
in  a  robot.  The  formalism  is  built  out  of  a  number  of  problem-solving 
primitives  together  with  a  hierarchical  multiprocess  backtrack  control 
structure.  Statements  can  be  asserted  and  perhaps  later  withdrawn  as 
the  state  of  the  world  changes.  Under  BACKTRACK  control  structure,  the 
hierarchy  of  activations  of  functions  previously  executed  is  maintained 
so  that  it  is  possible  to  revert  to  any  previous  state.  Thus  programs 
can  easily  manipulate  elaborate  hypothetical  tentative  states.  In  addi¬ 
tion  PLANNER  uses  multiprocessing  so  that  there  can  be  multiple  loci  of 
control  over  the  problem-solving.  Conclusions  can  be  drawn  from  the  various 
changes  in  state.  Goals  can  be  established  and  dismissed  when  they  are 
satisfied.  The  deductive  system  of  PLANNER  is  subordinate  to  the  hier¬ 
archical  control  structure  in  order  to  maintain  the  desired  degree  of 
control.  The  use  of  a  general-purpose  matching  language  as  the  basis 
of  the  deductive  system  increases  the  flexibility  of  the  system.  Instead 
of  explicitly  naming  procedures  in  calls,  procedures  can  be  invoked  im¬ 
plicitly  by  patterns  of  what  the  procedure  is  supposed  to  accomplish. 

The  language  is  being  applied  to  solve  problems  faced  by  a  robot,  to 
write  special  purpose  routines  from  goal  oriented  language,  to  express 
and  prove  properties  of  procedures,  to  abstract  procedures  from  proto¬ 
cols  of  their  actions,  and  as  a  semantic  base  for  English. 
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interested  in  pattern  aatching  oeed  read  only  sections  4.1,  4.2,  4.3, 
and  4.4.  Chapter  5  begins  the  systeaatic  explanation  of  PL1VVEB.  It 
introduces  the  priaitives,  data  structure,  and  control  structure  of 
the  language.  In  contrast  to  the  quantif icational  calculus,  the 
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seaantics  of  PLANBEB  ace  expressed  in  terns  of  the  properties  of  the 
procedures  which  define  the  foraalisa.  In  chapter  7  we  explain  how 
properties  of  FLAHHEfi  procedures  can  be  expressed  and  proved  in  the 
foraalisa  itself.  Also  we  attach  the  problea  of  how  it  is  possible  to 
teach  a  problea  solver  new  knowledge,  ie  explain  how  scheaata  give 
the  beginning  of  a  theory  on  the  coaparative  problea  solving  power  of 
various  computational  aodels  in  chapter  6. 
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1.  Hhat  Achilles  Said  To  The  Tortoise 

Levis  Carroll 


Achilles  had  overtaken  the  Tortoise ,  and  had  seated  hiaself 
comfortably  on  its  back. 

"So  you've  get  to  the  end  of  our  race-course?"  said  the 
Tortoise.  "Bven  though  it  does  consist  of  an  infinite  series  of 

distances?  I  thought  soae  viseacre  or  other  had  proved  that  the 

thing  couldn't  be  dene?" 

"It  can  be  done,"  said  Achilles.  "It  has  teen  done!  Solvitur 
anbulando.  You  see  the  distances  vere  constantly  diminishing:  and  so- 
_w 

"But  if  they  had  been  constantly  increasing?"  the  Tortoise 
interrupted.  "Bov  then?" 

"Then  I  shouldn't  be  here,"  Achilles  nodestly  replied:  "and 
you  vould  have  got  several  tines  round  the  vorld,  by  this  tine!" 

"You  flatter  ne —  flatten,  I  mean,"  said  the  Tortoise;  "Por 
you  are  a  heavy  veight,  and  no  aistake!  Hell  nov,  vould  you  like  to 

hear  of  a  race-course,  that  aost  people  fancy  they  can  get  to  the  end 

of  in  tvo  or  three  steps,  while  it  really  consists  of  an  infinite 
nuaber  of  distances,  each  one  longer  than  the  previous  one?" 

"Very  auch  indeed!"  said  the  Grecian  warrior,  as  he  drew  froa 
his  helaet  {few  Grecian  warriors  possessed  pockets  in  those  days)  an 
enoraous  note-book  and  a  pencil.  "Proceed!  And  speak  slowly,  please! 
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Short-hand  isn't  invented  yet!" 

"That  beautiful  First  Proposition  of  Euclid!"  the  Tortoise 
murmured  dreaaily.  "Ycu  adaire  Euclid?" 

"Passionately!  So  far,  at  least,  as  one  can  adaire  a  treatise 
that  won’t  be  published  for  some  centuries  tc  cone!" 

"Well,  now,  let’s  take  a  little  bit  of  the  argument  in  that 
First  Proposit ion-- just  two  steps,  and  the  conclusion  drawn  from  thea. 
Kindly  enter  the*  in  your  note-book.  And,  in  order  to  refer  to  thea 
conveniently,  let’s  call  thea  A,  B,  and  Z: 

(A)  Things  that  are  equal  to  the  saae  are  equal  to  each  other. 

(B)  The  two  sides  of  this  Triangle  are  things  that  are  equal 
to  the  saae. 

(Z)  The  two  sides  of  this  Triangle  are  equal  to  each  other. 

"Headers  of  Euclid  will  grant,  I  suppose,  that  Z  follows 
logically  froa  A  and  B,  so  that  any  one  who  accepts  A  and  B  as  true, 
must  accept  Z  as  true?" 

"Undoubtedly!  The  youngest  child  in  a  High  School —  as  soon  as 
High  Schools  are  invented,  which  will  net  be  till  scae  two  thousand 
years  later — will  grant  that." 

"And  if  soae  reader  had  not  yet  accepted  A  and  E  as  true,  he 
aight  still  accept  the  Sequence  as  a  valid  one,  I  suppose?" 

"No  doubt  such  a  reader  aight  exist.  He  aight  say  *1  accept 
as  true  the  Hypothetical  Proposition  that,  if  A  and  B  be  true,  Z  aust 
be  true;  but  I  don't  accept  A  and  B  as  true.'  Such  a  reader  would  do 
wisely  in  abandoning  Euclid,  and  taking  to  football." 
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"And  aight  there  not  also  be  scae  reader  who  would  say  'I 

accept  A  and  B  as  true,  but  I  don't  accept  the  Hypothetical'?" 

"Certainly  there  light.  He,  also,  had  better  take  to 
foottall." 

"And  neither  of  these  readers,"  the  Tortoise  continued,  "is  as 
yet  under  any  logical  necessity  to  accept  Z  as  true?" 

"Quite  so,"  Achilles  assented. 

"Bell,  now,  I  want  you  to  consider  ie  as  a  reader  of  the 
second  kind,  and  to  force  ae,  logically,  to  accept  Z  as  true." 

"A  tortoise  playing  football  would  be — "  Achilles  was 
beginning. 

" — an  anoialy,  of  course,"  the  Tortoise  hastily  interrupted, 
"don't  wander  froa  the  point.  Let's  have  Z  first,  and  football 
afterwards!" 

"I* a  to  force  you  to  accept  Z,  aa  I?"  Achilles  said  ausisgly. 
"And  your  present  position  is  that  you  accept  A  and  B,  but  you  don't 
accept  the  Hypothetical — " 

"Let's  call  it  C,"  said  the  Tortoise. 

* — but  you  don't  accept: 

(C)  If  A  aid  E  are  true,  Z  aust  be  true." 

"That  is  ay  present  positoa, "  said  the  Tortoise. 

"Then  I  aust  ask  you  to  accept  C." 

"I'll  do  so,"  said  the  Tortoise,  "as  soon  as  you've  entered  it 
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in  that  note-book  of  yours.  Bhat  else  have  you  got  in  it?" 

"Only  a  few  aeaoranda,"  said  Achilles,  nervously  flutteiing 
the  leaves:  "a  few  letoranda  of— »of  the  battles  in  which  I  have 
distinguished  nyself!" 

"Plenty  of  blank  leaves,  I  see!"  the  Tortoise  cheerily 
remarked.  "He  shall  need  thea  all!"  {Achilles  shuddered.)  "Now  write 
as  I  dictate: 

(A)  Things  that  ace  egual  to  the  saae  are  equal  each  other. 

(B)  The  two  sides  of  this  triangle  are  things  that  are  egual 
to  the  saae. 

(C)  If  A  and  B  are  true,  Z  aust  be  true. 

(ZJ  The  two  sides  of  this  Triangle  are  egual  to  each  other." 

"You  should  call  it  0,  not  Z,"  said  Achilles.  "It  cones  next 
to  the  other  three.  If  you  accept  A  and  B  and  C,  you  aust  accept  Z." 

"And  why  aust  I?" 

"Because  it  follows  logically  fron  thea.  If  A  and  B  and  C  are 
true,  Z  aust  be  true.  You  don’t  dispute  that,  I  iaagine?" 

"If  A  and  B  and  C  are  true,  Z  aust  be  true,"  the  Tortoise 
thoughtfully  repeated.  "That’s  another  Hypothetical  isn’t  it?  And, 
if  I  failed  to  see  its  truth,  I  night  accept  A  and  B  and  C,  snd  still 
not  accept  Z,  nightn’t  I?" 

"You  night,"  the  candid  hero  adnitted;  "though  such  obtuseness 
would  certainly  be  pbenoaenal.  Still,  the  event  is  possible.  So  X 
aust  ask  you  to  grant  one  aore  Hypothetical." 


"Very  good.  I’a  guite  willing  to  grant  Z,  as  soon  as  you’ve 
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written  it  down.  We  will  call  it 

(D)  If  A  and  B  and  c  are  true,  Z  wust  be  true. 

"Have  you  entered  that  in  your  note-book?" 

"I  have!"  Achilles  joyfully  exclaiaed,  as  he  ran  the  pencil 
into  its  sheath.  "And  at  last  we've  got  to  the  end  of  this  ideal 
race-course!  Now  tbat  you  accept  A  and  B  and  C  and  0,  of  course  you 
accept  Z." 

"Do  I?"  said  the  Tortoise  innocently.  "Let's  take  that  quite 
clear.  1  accept  A  and  B  and  C  and  0.  Suppose  I  still  refuse  to 
accept  Z?" 

"Then  Logic  would  take  you  by  the  throat,  and  force  yon  to  do 
it!"  Achilles  triuaphantly  replied.  "Logic  would  tell  you  can't  help 
yourself.  Nov  that  you've  accepted  A  and  B  and  C  and  D,  you  aast 
accept  Z!'  So  you've  no  choice,  you  see." 

"Whatever  Logic  is  good  enough  to  tell  ae  is  worth  writiag 
down,"  said  the  Tortoise.  "So  enter  it  in  your  book,  please.  Be  will 
call  it 


(E)  If  A  and  B  and  C  and  0  are  true,  Z  wust  be  true. 

"Until  I've  granted  that,  of  course,  I  needn't  grant  X.  So 
it's  quite  a  necessary  step,  you  see?" 

"1  see,"  said  Achilles;  and  there  was  a  touch  of  sadness  in 
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his  tone. 
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2.  The  Structural  Foundations  of  Problea  Solving 


Ke  would  like  to  develop  a  foundation  tor  problem  solving 
analogous  in  sene  «ays  to  the  currently  existing  foundations  for 
aat hematics.  Thus  ve  need  to  analyze  the  structure  of  foundations 

for  ea chenatics.  A  foundation  for  natheaatics  aust  provide  a 
definitional  formalism  in  vhich  aatheaatical  objects  can  be  defined 
and  their  existence  proved.  For  exaaple  set  theory  as  a  foundation 
provides  that  objects  aust  be  built  out  of  sets.  Then  there  aust  be  a 
deductive  foraalisa  in  vhich  fundamental  truths  can  be  stated  and  the 
aeans  provided  to  deduce  additional  truths  froa  those  already 
established.  Current  aatheaatical  foundations  such  as  set  theory 
seea  goite  natural  end  adequate  for  the  vast  body  of  classical 
natheaatics.  The  objects  and  reasoning  of  most  aatheaatical  doaains 
such  as  analysis  and  algebra  can  be  easily  founded  on  set  theory.  The 
existence  of  certain  astroncaically  large  cardinals  poses  soae 
probieas  for  set  theoretic  foundations.  Bovever,  the  problems  posed 
sees  to  be  of  practical  iaportance  only  to  certain  category  theorists. 
Foundations  of  sathesatics  have  devoted  a  great  deal  of  attention  to 
the  probieas  of  consistency  and  completeness.  The  problem  of 
consistency  is  important  since  if  the  foundations  are  i inconsistent 
then  any  for  aula  nhatsoever  nay  be  deduced ,  thus  trivializing  the 
foundations.  Semantic s  for  foundations  of  natheaatics  are  defined 
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oodel  theoretically  in  terns  of  the  notion  of  satisfiability.  The 
problem  of  covpleteness,  is  that  for  a  foundation  of  mathematics  to  be 
intuitively  satisfactory  all  the  true  formulas  should  be  proveable 
since  a  foundation  for  mathematics  aims  to  be  a  theory  of  mathematical 
truth. 

Similar  fundaaental  questions  must  be  faced  by  a  foundation 
for  problem  solving.  However  there  are  some  important  differences 
since  a  foundation  for  problem  solving  aims  more  to  be  a  theory  of 
actions  and  purposes  than  a  theory  of  mathematical  truth.  A 
foundation  for  problem  solving  must  specify  a  goal-oriented  formalism 
2" i  which  problems  can  be  stated.  Furthermore  there  must  be  a 
formalism  for  specifying  the  allowable  methods  of  solution.  As  part 
of  the  definition  of  the  formalisms,  the  following  elements  must  be 
defined:  the  data  structure,  the  control  structure,  and  the 

primitive  procedures.  Being  a  theory  of  actions,  a  foundation  for 
problem  solving  must  confront  the  problem  of  change:  How  can  account 
be  taken  of  the  changing  situation  in  the  world?  In  order  for  there 
to  be  problem  solving,  there  must  be  an  active  agent  called  a  problem 
solver.  A  foundation  for  problem  solving  must  consider  how  much 
knowledge  and  what  kind  of  knowledge  problem  solvers  can  have  about 
themselves.  Ir  contrast  to  the  foundation  of  mathematics,  the 
semantics  for  a  foundation  for  problem  solving  should  be  defined  in 
terms  of  properties  cf  procedures.  He  would  like  to  see  mathematical 
investigations  on  the  adequacy  of  the  foundations  for  problem  solving 
provided  by  PtiSMSB.  In  chapter  8  we  have  begun  one  kind  of  such  an 
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in vestigat ion. 

To  be  sore  specific,  a  foundation  for  problem  solving  aust 
concern  itself  with  the  following  coaplex  of  topics: 

PROCEDURAL  EMBEDDING:  How  can  "real  world"  knowledge  be 
effectively  embedded  in  procedures.  What  are  good  ways  to  express 
problea  solution  aethods  and  how  can  plans  for  the  solution  of 
problems  be  formulated? 

GENERALIZED  COMPILATION:  ihat  are  good  aethods  for  transforaing 
high  level  goal-oriented  language  into  efficient  algorithms. 

VERIFICATION:  How  can  it  be  verified  that  a  procedure  does  what 

is  intended. 

PROCEDURAL  ABSTRACTION:  Hhat  are  good  aethods  for  abstracting 
general  procedures  froa  special  cases. 

One  foraulation  of  a  foundation  for  probler  solving  regui.res 
that  there  should  be  two  distinct  foraalisas: 

1:  A  METHODS  foraalisa  which  specifies  the  allowable  aethods  of 

solution 

2:  A  PROBLEM  SPECIFICATION  foraalisa  in  which  to  pose  problems. 

The  problea  solver  is  expected  to  figure  out  how  to  combine  its 
available  aethods  in  order  to  produce  a  sr 'ution  which  satisfies  the 
problem  specification.  One  of  the  aims  of  the  above  formulation  of 
problem  solving  is  to  clearly  separate  the  methods  of  solution  from 
the  problems  posed  so  that  it  is  impossible  to  "cheat"  and  give  the 
problem  solver  the  aethods  for  solving  the  problea  along  with  the 
statement  of  the  problea.  Be  propose  to  bridge  the  chasm  between  the 
methods  foraalisa  and  the  problea  foraalisa.  Consider  more  carefully 
the  two  extremes  in  the  specification  of  processing: 
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A:  Explicit  processing  (e.g.  aethods)  is  the  ability  to  specify 
and  control  actions  down  to  the  finest  details. 

B:  Iapiicit  processing  (e.g.  probleas)  is  the  ability  to  specify 

the  end  result  desired  and  not  to  say  nuch  about  how  it  should  be 
achieved. 

PLANNER  attempts  to  provide  a  fornalis*  in  which  a  prcblea  solver  can 
bridge  the  continuaa  between  explicit  and  iapiicit  processing.  We  aim 
for  a  aaxitua  of  flexibility  so  that  whatever  knowledge  is  available 
can  be  incorporated,  even  if  it  is  fragaentary  and  heuristic. 

PLANNER  is  a  high  level,  goal-oriented  foraalisa  in  which  one 
can  specify  to  a  large  degree  what  one  wants  done  rather  than  how  to 
do  it.  Many  c  l  tfc«'  priaitives  in  PLANNER  are  concerned  with 
manipulating  a  data  base  in  a  pattern  directed  fashion.  Host  of  the 
priaitives  have  been  developed  as  extensions  to  the  foraalisa  when  we 
have  found  problems  that  could  not  otherwise  be  solved  in  a  natural 
way.  Of  course  the  trick  is  to  incorporate  the  new  primitive  as  a 
genuine  extension  of  wide  applicability.  Others  have  suggested 
themselves  as  adjuncts  in  order  to  obtain  useful  closure  properties  in 
the  foraalisa.  We  would  be  grateful  to  any  reader  who  could  suggest 
probleas  that  would  seea  to  require  farther  extensions  or 
aodif icfc tions  to  the  foraalisa. 

There  are  aany  ways  in  which  one  can  approach  a  description  of 
PLANNEB.  In  this  section  we  will  describe  PLANHEB  froa  an  Inforaation 
Processing  Viewpoint.  To  do  this  we  will  describe  the  data  structure 
and  the  control  structure  of  the  foraalisa. 


GLOBAL  DATA  BASE 


[ABOVE  ABl  is  not  in  the  global 
data  base 


PLANNER  ALLOWS  FOR  THE  SIMULTANEOUS 
EXISTENCE  OF  INCOMPATIBLE  LO^AL  STATES 
IN  MODELS. 
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DATA  STRUCTURE: 

GBAPH  MEMORY  ferns  the  basis  for  PLANNEE’S  data  space  which 
consists  of  directed  graphs  with  labeled  arcs.  Tne  operation 
of  PUTTING  and  GETTING  the  components  of  data  objects  have 
been  generalized  to  apply  to  any  data  type  whatsoever.  Por 
example  to  PUT  the  value  CANONICAL  on  the  expression  <♦  X  Y  <* 
X  Z>>  under  the  indicator  SIflPLIFIED  is  one  way  to  record  that 
<♦  X  I  <*  X  Z>>  has  been  canonically  simplified.  Then  the 
degree  to  which  an  expression  is  simplified  can  be  determined 
by  GETTING  the  value  under  the  indicator  SIMPLIFIED  of  the 
expression.  The  operations  of  PUT  and  GET  can  be  implemented 
efficiently  using  hash  coding.  Lists  and  vectors  have  been 
introduced  to  gain  more  efficiency  for  common  special  purpose 
structures.  The  graph  memory  is  useful  to  PLANNER  in  many 
ways.  Monitoring  gives  PLANNER  the  capability  of  trapping 
all  read,  write,  and  execute  references  to  a  particular  data 
object.  The-  monitor  {which  is  found  under  the  indicator 
MONITOR)  of  the  data  object  can  then  take  any  action  that  it 
sees  fit  in  order  to  handle  the  situation.  The  graph  memory 
can  be  used  to  retrieve  the  value  of  an  identifier  i  of  a 
process  p  by  GETTING  the  i  component  of  p.  Code  can  be 
commented  by  siwply  PUTTING  the  actual  comment  under  the 
indicator  COMMENT.  Also  graph  memory  enables  unique  copies  of 
structures  to  be  efficiently  and  conveniently  stored. 

DATA  BASE:  What  is  most  distinctive  about  the  way  in  which 
PLANNER  uses  data  is  that  it  has  a  data  base  in  which  data  can 
be  inserted  and  removed.  For  example  inserting  [AT  B1  P2  ] 
into  the  data  base  might  signify  that  block  B1  is  at  the  place 
P2.  A  coordinate  of  an  expression  is  defined  to  be  an  atom  in 
some  position.  An  expression  is  determined  by  its 
coordinates.  Assertions  are  stored  in  buckets  by  their 
coordinates  using  the  graph  memory  in  order  to  provide 
efficient  retrieval.  In  addition  a  total  ordering  is  imposed 
on  the  assertions  so  that  the  buckets  can  be  sorted. 
Imperatives  as  well  as  declaratives  can  be  stored  in  the  data 
base.  We  might  assert  that  whenever  an  expression  of  the 
form  [AT  objectl  placel]  is  removed  from  the  data  base,  then 
any  expression  in  the  data  base  of  the  form  [CN  objectl 
object2]  should  also  be  removed  from  the  data  base.  The  data 
base  can  be  tree  structured  so  that  it  is  possible  to 
simultaneously  have  several  local  data  bases  which  are 
incompatible.  Furthermore  assertions  in  the  data  base  can 
have  varying  scopes  so  that  some  will  last  the  duration  of  a 
process  while  ethers  are  temporary  to  a  subroutine. 


CONTROL  STRUCTURE:  PLANNER  uses  a  pattern  directed  multiprocess 
backtrack  control  structure  to  tie  the  operation  of  its  primitives 
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together. 

BACKTRACKING:  PLANNER  processes  have  the  capability  of 

backtracking  tc  previous  states.  A  process  can  backtrack  into 
a  procedure  activation  (i.e.  a  specific  instance  of  an 
invocation  of  a  procedure)  which  has  already  returned  with  a 
result.  Using  the  theory  of  comparative  scheiatology, 
have  proved  in  chapter  8  that  the  use  of  backtrack  control 
enables  ns  to  achieve  effects  that  a  language  (such  as  LISP) 
which  is  limited  to  recursive  control  cannot  achieve. 
Backtracking  preserves  the  nesting  of  the  subroutine  structure 
of  PLANNER  while  allowing  the  consequences  of  elaborate 
tentative  hypotheses  to  be  explored  without  losing  the 
capability  of  rejecting  the  hypotheses  and  all  of  their 
consequences.  A  choice  can  be  made  on  the  basis  of  the 
available  knowledge  and  if  it  doesn't  work,  a  better  choice 
can  be  made  using  the  new  information  discovered  while 
investigating  the  first  choree.  Also  backtrack  control  makes 
PLANNER  procedures  easier  to  debug  since  they  can  be  run 
backwards  as  well  as  forwards  enabling  a  problem  solver  to 
"zero  i'c4  on  bugs. 


MULTIPROCESSING  gives  PLAKNER  the  capability  of  having  more 
than  one  locus  of  control  in  problem  solving.  By  using 
multiple  processes,  arbitrary  patterns  of  investigation 
through  a  conceptual  problem  space  can  be  carried  out. 
Processes  can  have  the  power  to  create,  read,  write, 
interrupt,  resume,  single  step,  and  fork  other  processes.  The 
ability  to  single-step  or  to  interrupt  processes  allows  the 
definition  of  procedures  which  are  NOT  monotone  in  the  sense 
of  lattice  theory.  Potentially  the  failure  of  monotoniciv.y  is 
a  serious  flaw  in  the  lattice  theoretic  approach  towards  a 
mathematical  foundation  for  effective  procedures. 

PATTrSN  DIRECTION  combines  aspects  of  control  and  data  stra*:ture« 
The  fundamental  principle  of  pattern  directed  computation  is  that 
a  procedure  should  be  a  pattern  of  what  the  procedure  is  intended 
to  accomplish.  In  other  words  a  procedure  should  not  only  do  the 
right  thing  but  it  should  appear  to  do  the  right  thing  as  well ! 
PLANNER  uses  pattern  direction  for  the  following  operations: 

CONSTRUCTION  of  structured  data  objects  is  accomplished  by 
templates.  He  can  construct  a  list  whose  first  element  is 
the  value  of  x  and  whose  second  element  ? s  the  value  of  y  by 
the  procedure  (x  y).  If  x  has  thm  value  J  and  y  has  the  value 
(A  B)  then  (x  y)  will  evaluate  to  (3  (A  B) ) . 

DECOMPOSITION  is  accomplished  by  matching  the  data  object 
against  a  structured  pattern,  if  the  pattern  (xl  x2)  is 
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matched  against  the  data  object  ((3  4)  A)  then  xl  will  be 
given  the  value  (3  4)  and  x2  will  be  given  the  value  A. 

RETRIEVAL:  An  assertion  is  retrieved  froa  the  data  base  by 
specifying  a  pattern  which  the  assertion  aust  Batch  and 
thereby  bind  the  identifiers  in  the  pattern.  Por  example  we 
can  deteraine  if  there  is  anything  in  the  data  base  of  the 
fora  [CH  x  A].  If  [ON  B  A]  is  the  only  itea  in  the  data  base, 
then  x  is  bound  to  B.  If  there  is  aore  than  one  itea  in  the 
data  base  which  Batches  a  retrieval  pattern,  then  an  arbitrary 
choice  is  Bade.  The  fact  that  a  choice  was  Bade  is  reaeabered 
so  that  if  a  siaple  failure  backtracks  to  the  decision, 
another  choice  can  be  aade. 

INVOCATION:  Procedures  can  be  invoked  by  patterns  of  what 
they  are  supposed  to  accoaplish.  Suppose  that  we  have  a 
stopped  sink.  One  way  we  could  try  to  solve  the  problea  would 
be  to  know  the  nane  of  a  pluaber  whoa  we  could  call.  An 
alternative  which  is  acre  analogous  to  pattern  directed 
invocation  is  to  advertise  the  fact  that  we  have  a  stopped 
sink  and  the  qualifications  needed  to  fix  it.  In  PLANNER  this 
is  accoaplished  by  aaking  the  advertiseaent  (i.e.  a  pattern 
which  represents  what  i;  desired)  into  a  goal.  The  procedure 
invoked  by  the  pattern  night  or  night  not  succeed  in  achieving 
the  goal  depending  on  the  enviionaent  in  which  it  was  called. 
The  procedure  invoked  can  be  required  to  undo  all  the  actions 
that  it  took  tc  try  to  achieve  the  goal.  For  exanple  if  we 
were  unhappy  with  the  way  in  which  a  pluaber  fixed  cur  sink, 
we  could  require  that  he  restore  the  situation  to  its  previous 
state.  Since  aany  theoreas  night  natch  a  goal,  a 
recoaaendation  is  allowed  as  to  which  of  the  candidate 
theoreas  night  be  useful.  The  recoaaendation  is  a  pattern 
which  a  candidate  tbeorea  aust  natch. 

One  basic  idea  behind  PLANNER  is  to  exploit  the  duality  that 
we  find  between  certain  iaperative  and  declarative  sentences. 

Consider  the  stateaent  (iaplies  A  B) .  The  stateaent  is  a  perfectly 
good  declarative.  In  addition,  it  can  also  have  certain  iaperative 
uses  for  PLAINER.  It  can  say  that  we  night  set  up  a  procedure  which 
will  note  whether  A  is  ever  asserted  and  if  so  to  consider  the  wisdom 
of  asserting  B  in  turn.  [Note:  it  is  not  always  wise!  Suppose  we 
assert  <integer  0>  and  (iaplies  <iateger  n>  <integer  (♦  n  1)  >J  ]. 
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Purtheraore  it  per  aits  us  to  set  up  a  procedure  that  will  watch  to  see 
if  it  is  ever  our  goal  to  try  to  deduce  B  and  if  so  whether  A  should 
be  aade  a  subgoal.  Exactly  the  saae  observations  can  be  Bade  about 
the  contrapositive  of  the  stateaent  (iaplies  A  BJ  which  is  {iaplies 
{not  8}  {not  A}}.  Stateaents  with  universal  quantifiers, 
conjunctions,  disjunctions,  etc.  can  also  have  both  declarative  and 
iaperative  uses.  PLAMHEB  taeoreas  are  used  as  iaperatives  when 
executed  and  as  declaratives  when  used  as  data.  The  iaperative 
analogues  have  the  advantage  that  they  can  aore  easily  express  any 
procedural  knowledge  that  we  aight  have  such  as  "Don't  use  this 
theorea  twice". 

Our  work  on  PLAHHEB  has  been  an  investigation  in  PBOCEDOBAL 
EPISTE HOLOGT ,  the  study  of  how  knowledge  can  be  eabedded  in 
procedures.  The  THESIS  OF  PBOCEDOBAL  BHBBDDIMG  is  that  intellectual 
structures  should  be  analyzed  through  their  PBOCEDOBAL  AIALOGOES.  He 
will  try  to  show  what  we  aean  through  exaaples: 

DESCBIPTXOIS  are  procedures  which  recognize  how  well  soae 
candidate  fits  the  description. 

PATTEBHS  are  descriptions  which  natch  configurations  of  data. 
For  exaaple  <either  4  <atonic>>  is  a  procedure  which  will 

recognize  soaethiag  which  is  either  4  or  is  atonic. 

DATA  TYPES  are  patterns  used  ia  declarations  of  the  allowable 
range  and  doaain  of  procedures  and  identifiers.  Bore 
generally,  data  types  have  analogues  in  the  fora  of  procedures 
which  create,  destroy,  recognize,  and  transfora  data. 

GBABBABS:  The  PBOGBABBAB  language  of  Terry  Hinograd  another 
step  towards  one  kind  of  procedural  analogue  for  natural 
language  graanar. 
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SCHISMATIC  DB ASIHGS  have  as  their  procedural  analogue  eethods 
for  recognizing  when  particular  figures  fit  within  the 
scheaata. 

PBGCFS  correspond  to  plans  for  recognizing  and  expanding  valid 
chains  of  deductions.  Indeed  nan;  proofs  can  fruitfully  be 
considered  to  define  procedures  which  are  proved  to  have 
certain  properties.  For  exanple  a  proof  by  natheaatical 
induction  of  a  effective  for  aula  p[n]  can  be  considered  to  be 
a  proof  that  the  following  function  always  returns  "TRUE": 

p[n]  :*  if  p[  0  ]  then  "TRUE**  else  p[n-1  ] 

Conversely,  proofs  by  execution  induction  cf  properties  of 
procedures  can  be  used  to  deaonstrate  mathematical  facts.  For 

exaaple  proofs  by  execution  induction  can  iaitate  proofs  by 
aatheaatical  induction: 


<f  n>  : 


=  <repeat  out .[[i.Q]]  .  . 

; "initialize  l  to  C" 

intent:  p[i] 

<cond 

[<is?  .i  .n> 

;"if  . i  is  equal  to  .n  then 
exit  with  the  value 


<.out  .n>]> 

<_  :i  <♦  .i  1» 

;"else  increaent  i  ard  repeat"> 


Proving  the  intention  p[i]  by  execution  induction  will 
establish  that  for  all  n  we  nave  p[n].  Proofs  by  execution 
induction  enable  global  properties  (such  as  convergence  and 
equivalence)  to  be  proved  by  purely  local  analysis. 


BODELS  are  collections  of  procedures  for  simulating  the 
behavior  of  the  systea  being  aodeled.  BODELS  of  PBOGBAMS  are 
procedures  for  defining  properties  of  procedures  and 
atteapting  to  verify  the  properties  so  defined.  Bodels  of 
prograas  can  be  defined  by  procedures  which  state  the 
relations  that  aust  hold  as  control  passes  through  the 
prograa. 


PLUS  are  general,  goal  oriented  procedures  for  atteapting  to 
carry  out  sone  task. 

T8 SOBERS  of  the  QOAITIFICATIOIAL  CALCOLOS  have  as  their 
analogues  procedures  for  carrying  out  the  deductions  which  are 
justified  by  the  theoreas.  For  exanple,  consider  a  theorem  of 
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the  for*  (IMPLIES  x  y} .  One  procedural  analogue  of  the 
theore*  is  to  consider  whether  x  should  be  aade  a  subjoal  in 
order  to  try  to  prove  soaething  of  the  for*  y. 

DRAWINGS:  The  procedural  analogue  of  a  drawing  is  a  procedure 
for  aaking  the  drawing.  Bather  sophisticated  display 
processors  have  been  constructed  for  Baking  drawings  on 
cathode  ray  tubes. 

RECOMMENDATIONS:  piiNNEB  has  priaitives  which  allow 

reconaendations  as  to  how  disparate  sections  of  goal  oriented 
language  should  be  linked  together  in  order  to  accoaplish  soae 
particular  task. 

GCAL  TBEES  are  represented  by  a  snapshot  of  the  instantaneous 
configuration  of  proble*  solving  processes. 

One  corollary  of  the  thesis  of  procedural  eabedding  is  that 
learning  entails  the  learning  of  the  procedures  in  which  the  knowledge 
to  be  learned  is  eabedded.  Another  aspect  of  the  thesis  of  procedural 
eabedding  is  that  the  process  of  going  froa  general  g'cal  oriented 
language  which  is  capable  of  accoaplishing  sene  task  to  a  special 
purpose,  efficient,  algorithas  especially  designed  for  the  task  should 
itself  be  aechanized.  By  expressing  the  properties  of  the  special 
purpose  algoritha  in  tcras  of  their  procedural  analogues,  we  can  use 
the  analogues  to  establish  that  the  special  purpose  routine  does  in 
fact  do  what  it  is  intended. 

Froa  the  above  observations,  we  have  constructed  a  foraalisa 
that  peraits  both  the  imperative  and  declarative  aspects  of  stateaents 
to  be  easily  aanipulated.  PLABKEB  uses  a  pattern-directed  inforaation 
retrieval  systea.  The  data  base  is  interrogated  by  specifying  a 
pattern  of  what  is  to  be  retrieved.  Instead  cf  having  to  explicitly 
naae  procedures  which  are  to  be  called,  they  can  be  invoked  iaplicitly 
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by  a  pattern  {this  important  concept  is  called  PATTERN-DIRECTED 
INVOCATION) .  when  a  statement  is  asserted,  reconasndations  deternine 
what  conclusions  will  fee  drawn  iron  the  assertion.  Procedures  can 
aake  recoaaendations  as  to  which  theoreas  should  be  used  in  trying  to 
draw  conclusions  froa  an  assertion,  and  they  can  reconnend  the  order 
in  which  the  theoreas  should  be  applied.  Goals  can  oe  created  and 
autoaatically  disaissed  when  they  are  satisfied.  Objects  can  be  found 
froa  scheaatic  or  partial  descriptions.  Provision  is  aade  for  the 
fact  that  stateaents  that  were  once  true  in  a  aodel  aay  no  longer  be 
true  at  soae  later  tiae  and  that  consequences  aust  be  drawn  froa  the 
fact  that  the  state  of  the  aodel  has  changed.  Assertions  and  goals 
created  within  a  procedure  can  be  dynaaically  protected  against 
iaterfetence  froa  othei  procedures.  ' Onlike  soae  otfier^toraalTsas  such 
as  GPS,  PLANHEH  has  no  explicit  goal  tree.  Instead  the  coaputation 
itself  can  be  thought  to  be  investigating  soae  conceptual  problea 
space.  Priaitives  for  a  aultiprocess  backtrack  control  structure 
give  flexibility  to  the  ways  in  which  the  conceptual  problea  space  can 
be  investigated.  Procedures  written  in  the  foraalisa  are  extendable 
in  that  they  can  aake  use  of  new  knowledge  whether  it  be  priaarily 
declarative  or  iaperative  in  nature.  Hypotheses  can  be  established  and 
latex  discharged.  PLAHHEB  has  been  used  to  write  a  block  coatrol 
language  in  which  we  specify  how  blocks  can  be  aoved  around  by  a 
robot.  He  would  like  to  write  a  structure  building  foraalisa  in 
which  we  could  provide  descriptions  of  structures  (such  as  houses  and 
bridges)  and  let  PLillEB  figure  out  how  to  build  then.  The  logical 
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deductive  systen  used  by  PLASREB  is  subordinate  to  the  hierarchical 

control  structure  of  the  language.  PLAHHEB  theorems  operate  within  a 
context  consisting  of  return  addresses,  goals,  assertions,  bindings, 
and  local  changes  of  state  that  have  been  nade  to  the  global  data 
base.  Through  the  use  of  this  context  -we  can  guide  the  coapotation 
and  avoid  doing  basically  the  saae  work  over  and  over  again,  For 
exaaple,  once  we  deteraine  that  we  are  working  within  a  group  (in  the 
aathenatical  sense}  we  can  restrict  our  attention  to  theoreaa  for 
working  on  groups  since  we  have  direct  control  over  what  theoreaa  will 
be  used.  PLAHNEB  has  a  sophisticated  deductive  systea  in  order  to 
give  us  greater  power  over  the  direction  of  the  coapotatioa.  Of 
course  procedures  written  in  PLAB1EB  are  not  intrinsically  efficient. 

A  great  deal  of  thought -and  effort  nost  be  put  into  writing  efficient 
procedures.  PLAMHEfi  does  provide  sone  basic  nechanisas  and 
priaitives  in  which  to  express  problea  solving  procedures.  The 
control  structure  can  still  be  used  shen  we  liait  ourselves  to  using 
resolution  as  the  sole  rule  of  inference.  A  nnifora  proof  procedure 
gives  very  little  control  over  how  or  when  a  theorea  is  used.  The 
problea  is  one  of  the  level  of  the  interpreter  that  is  used.  I 
digital  computer  by  itself  will  only  interpret  the  hardware 
instructions  of  the  aachine.  A  higher  level  in ter peter  such  as  LISP 
will  interpret  assignments  and  recursive  function  calls.  At  a  still 
higher  level  an  interpreter  such  as  BATCBLXSS  will  interpret  patterns 
for  constructing  and  decomposing  structured  data.  PLAIBE1  can 
interpret  assertions,  find  statenents,  and  goals.  It  goes  without 
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saying  that  code  can  be  co»p.iled  for  any  of  the  higher  level 
interpeters  so  that  it  actually  runs  under  a  lower  level  interpreter. 
In  general  higher  level  interpreters  have  greater  choice  in  the 
actions  that  they  can  take  since  instructions  are  phrased  more  In 
terns  of  goals  to  be  achieved  rather  than  in  terns  of  explicit 
eleaentary  actions.  The  problen  that  we  face  is  to  raise  the  level  of 
the  interpreter  while  at  the  sane  tine  keeping  the  actions  taken  by  it 
under  control.  Due  to  its  extrene  hierarchical  control  and  its 
ability  to  make  use  cf  new  isperative  as  well  as  declarative 
knowledge,  it  is  feasible  to  carry  out  very  long  chains  of  inference 
in  PLANWEfi  without  extrene  inefficiency. 

He  are  concerned  as  to  how  a  theorem  prover  can  unify 
structural  problen  solving  nethods  with  domain  dependent  algorithms 
and  data  into  a  coherent  problem  solving  process.  By  structural 
nethods  we  mean  those  that  are  concerned  with  the  formal  structure  of 
the  argument  rather  than  with  the  semantics  of  its  domain  dependent 
content. 

An  example  of  a  structural  method  is  the  "consequences  of  the 
consequent"  heuristic.  By  the  CONSECOENCES  CF  THE  CCKSECUEHT 
heuristic,  we  nean  that  a  problem  solver  should  lock  at  the 
consequences  of  the  goal  that  is  being  attempted  in  order  to  get  an 
idea  of  some  of  the  statements  that  could  be  useful  in  establishing  or 
rejecting  the  goal. 

He  need  to  discover  more  powerful  structural  nethods.  PLANNEB 
is  intended  to  provide  a  computational  basis  for  expressing  structural 
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aethods.  One  of  the  arst  important  ideas  in  PLAMBEB  is  that  it  brings 

soee  of  the  stroctaral  aethods  of  problea  solving  out  into  the  open 
where  they  can  be  analyzed  and  generalized.  There  are  a  few  basic 
patterns  of  looping  and  recursion  that  are  in  constant  use  aaong 
prograaaers.  Ezaaples  are  recursion  cn  binary  trees  as  in  LISP  and 
the  FIND  stateaent  of  PLAMHEB.  The  priaitive  PIDD  will  construct  a 
list  of  the  objects  with  certain  properties.  For  exaaple  we  can  find 
five  things  which  are  on  soaething  which  is  green  by  evaluating 

<FIBD  5  X 

<GOAL  £  OB  x  y ]> 

<GOAL  [GHEE*  y  ]» 

which  reads  "find  5  x's  such  that  x  is  OR  y  and  y  is  GREEK. 

The  patterns  cf  looping  and  recursion  represent  coaaon 

...  • 

structural  aethods  used  in  progress.  They  specify  hew  ccaaands  can  be 
repeated  iteratively  and  recursively.  One  of  the  aain  problems  in 
getting  coaputers  to  write  progress  is  how  to  use  these  structural 
patterns  with  the  particular  dcaain  dependent  coaaands  that  are 
available.  It  is  difficult  to  decide  which  if  any  of  the  basic 
patterns  is  appropriate  in  any  given  problea.  The  problea  of 
synthesizing  progress  out  of  canned  loops  is  foraally  identical  to  the 
problea  of  finding  proofs  using  aatheaatical  induction.  He  have 
approached  the  problea  of  constructing  procedures  out  of  goal  oriented 
language  froa  two  directions.  The  first  is  to  use  canned  loops  (such 
as  t le  FXID  stateaent)  where  we  assuae  a-priori  the  kind  cf  control 
structure  that  is  needed.  The  second  approach  is  to  try  to  abstxact 
the  procedure  froa  protocols  of  its  action  in  particular  cases. 


CONSEQUENT 


ULTIMATE  GOAL) 


CONSEQUENCES  OF 
CONSEQUENT 
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Another  structural  method  is  EBOGHESSIVE  BEFIREHENT.  The  way 
problems  are  solved  by  progressive  refinement  is  by  repeated 
evaluation.  Instead  of  trying  to  do  a  complete  investigation  of  the 
problem  space  all  at  once,  repeated  refinements  are  made.  For  example 
in  a  game  like  chess  the  same  part  of  the  game  tree  might  be  looked  at 
several  times.  Each  time  certain  path,  are  more  deeply  explored  in 
the  light  of  what  other  investigations  have  revealed  to  be  the  key 
features  of  the  position.  Problems  in  design  seem  to  be  particularly 
suitable  for  the  use  of  progressive  refinement  sir.ce  proposed  designs 
are  often  amenable  to  successive  refinement.  The  way  in  which 
progressive  refinement  typically  is  done  in  ELAHHEE  is  by  repeated 
evaluation.  Thus  the  expression  which  is  evaluated  to  solve  the 
problem  will  itself  produce  as  its  value  an  expressxon.to  be 
evaluated. 

The  task  of  artificial  intelligence  is  to  program  inaaimate 
machines  to  perform  tasks  that  reguire  intelligence.  Over  the  past 
decade  several  different  approaches  toward  A.  I.  have  developed. 
Although  very  pure  forms  of  these  approaches  will  seldom  be  met  in 
practice,  we  find  that  it  is  useful  for  purposes  of  discussion  to 
consider  these  conceptual  extremes.  One  approach  (called  results  mode 
by  S.  Papert)  has  been  to  choose  some  specific  intellectual  task  that 
humans  can  perform  with  facility  and  write  a  program  to  perform  it. 
Several  very  fine  programs  have  been  written  following  this  approach. 
One  of  the  first  was  the  Logic  Theorist  which  attempted  to  prove 
theorems  in  the  propositional  calculus  using  the  deductive  system 
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developed  in  Principia  Mather.atica.  The  importance  of  the  Logic 
Theorist  is  that  it  developed  a  body  of  techniques  which  when  cleaned 
up  and  generalized  have  proved  to  be  fundamental  tc  furthering  oar 
understanding  of  A.  I.  The  results  mode  approach  offers  the 
potentiality  of  maximum  efficiency  in  solving  particular  classes  of 
problems.  On  the  other  hand,  there  have  been  a  number  of  programs 
written  from  the  results  mode  approach  which  have  not  advanced  our 
understanding  although  the  programs  achieved  slightly  better  results 
than  had  been  achieved  before.  These  programs  have  been  large, 
clumsy,  brute  force  pieces  of  machinery.  There  is  a  clear  danger  that 
the  results  mode  approach  can  degenerate  into  trying  to  achieve  A.  I. 
/ia  the  "hairy  kludge  a  month  plan".  The  problems  with  "hairy 
kludges"  are  well  known.  It  is  impossible  to  get  such  programs  to 
communicate  with  each  other  in  a  natural  and  intimate  way.  They  are 
difficult  to  understand,  extend,  and  nodify  because  of  the  ad  hoc  way 
in  which  they  are  constructed. 

Another  approach  to  A.  1.  that  has  been  prominent  in  the  last 
decade  is  that  of  the  uniform  proof  procedure.  Proponents  of  the 
approach  rrite  programs  which  accept  declarative  descriptions  of 
combinatorial  problems  and  then  attempt  to  solve  them.  In  its  most 
pure  form  the  approach  does  not  permit  the  machine  to  be  given  any 
information  as  to  how  it  might  solve  its  problems.  The  character 
table  approach  to  A.  I.  is  a  modification  of  the  uniform  procedure 
approach  in  which  the  program  is  also  given  a  finite  state  table  of 
connections  between  goals  and  methods.  The  uniform  procedure  approach 
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offers  a  great  deal  of  elegance  and  a  taxiaua  of  a  certain  kind  of 
generality.  Current  prograas  that  iapleaent  the  unifora  procedure 
approach  suffer  fcoa  extrese  inefficiency.  8e  believe  that  the 
inefficiency  is  intrinsic  in  the  approach. 

FLAM9EE  is  not  neccessarily  general  in  the  sane  sense  that  a 
unifora  proof  procedure  is  general.  PLAMHEB  is  intended  to  be  a 
natural  coapntational  basis  for  aethods  of  solving  probleas  in  a 
doaain.  A  coaplete  proof  procedure  for  a  guantif icational  calculus 
is  general  in  the  sense  that  if  one  can  force  the  Droblea  into  the 
fora  of  the  input  language  and  is  prepared  to  wait  eons  if  necessary, 
then  the  coaputer  is  guaranteed  to  find  a  solution  if  there  is  one. 

The  approach  taken  in  PLAHH2B  is  to  subordinate  the  deductive  systea 
to  an  elaborate  hierarchical  control  structure.  Although  PLAHRBB 
itself  is  doaain  independent,  procedures  written  in  it  have  differing 
overlapping  degrees  of  doaain  independence.  Proponents  of  the  unifora 
procedure  approach  are  apt  to  say  that  P1AHHEB  "cheats"  because 
through  the  use  of  its  hierarchical  control  structure,  it  is  possible 
to  tell  the  prograa  how  to  try  to  solve  its  probleas.  In  order  to 
prevent  this  kind  of  "cheating",  they  would  restrict  the  input  to 
consist  entirely  of  declaratives.  But  surely,  it  is  to  the  credit  of 
a  prograa  that  it  is  able  to  accept  new  iaperative  inroraation  and 
aake  use  of  it.  A  problea  solver  needs  a  high  level  language  for 
expressing  problea  solving  aethods  even  if  the  language  is  only  used 
by  the  problea  solver  to  express  its  problea  solving  aethods  to 
itself.  PLAIREB  serves  both  as  the  language  in  which  probleas  are 
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posed  to  the  problea  solver  and  the  language  In  which  aethods  of 

solution  are  foraulated.  PLAHH122  is  not  intended  to  be  a  solution  to 
the  problea  of  finding  general  aethods  for  reducing  the  coabinatorial 
search  involved  to  test  whether  a  given  proposition  is  valid  or  not. 

It  is  intended  to  be  a  general  foraalisa  in  which  knowledge  cf  a 
domain  can  be  coabined  and  integrated.  Realistic  problea  solving 
prograas  will  need  vast  aaounts  of  knowledge,  He  consider  all  aethods 
of  solving  prcbleas  to  be  legitiaate.  If  a  prograa  should  happen  to 
already  know  the  answer  to  the  problea  that  it  is  asked  to  solve,  then 
it  is  perfectly  reasonable  for  the  prcblea  to  be  solved  by  table  look¬ 
up.  He  should  use  the  criterion  that  the  problea  solving  power  of  a 
prograa  should  increase  auch  faster  than  in  direct  proportion  to  the 
nunber  of  things  that  it  is  told.  The  iaportant  factors  in  judging  a 
prograa  are  its  power,  elegance,  generality,  and  efficiency. 
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3.  Discursive  Overview 


This  chapter  contains  an  explanation  of  soae  of  the  ideas  in 
PLANNER  in  essay  fora.  It  is  partially  based  or*  a  draft  written  by  T. 
Hinograd  for  the  course  6.545.  If  the  reader  would  like  to  see  a  tore 
systematic  presentation,  he  can  consult  the  subsequent  chapters. 

The  easiest  way  to  understand  PLANNEE  is  to  watch  how  it 
works,  so  in  this  section  we  will  present  a  few  siaple  exaaples  and 
explain  the  use  of  soae  of  its  aost  eleaentary  features.  These 
exaaples  are  not  intended  to  represent  TOT  PBOBLEHS  to  serve  as  test 
cases  for  "general  profclea  solvers".  The  toy  problea  naradiga  is 
misleading  because  toy  probleas  can  be  solved  without  any  real 
knowledge  o£  the  domain  in  which  the  toy  problea  is  posed.  Indeed,  it 
seems  gauche  to  use  acy  thing  as  powerful  as  real  knowledge  on  such 
staple  probleas.  In  contrast  we  believe  that  real  world  probleas 
reguire  vast  aaounts  of  procedural  knowledge  for  their  solution.  Be 
see  it  as  part  of  our  task  to  provide  the  intellectual  capabilities 
needed  for  effective  problea  solving.  Me  would  like  to  see  the  toy 
problea  pacadiga  replaced  with  an  INTELLECTUAL  CAPABILITY  paradigm 
where  the  object  is  to  illustrate  the  intellectual  capabilities  needed 
so  that  knowledge  can  be  effectively  embedded  in  procedures. 

First  we  will  take  the  aost  venerable  of  traditional 
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Turing  is  a  human 
All  humans  are  fallible 
so 

Turing  is  fallible. 

It  is  easy  enough  to  see  ho*  this  could  be  expressed  in  the 
usual  logical  notation  and  handled  by  a  uniform  proof  procedure. 
Instead,  let  us  express  it  in  one  possible  way  to  PLANNER  by  saying: 

<ASSEBT  [HtJHAN  TORING]> 

<ASSERT  <DEFINE  THEOREM  1 

CONSEQUENT  [Y]  [  FALLIBLE  ?Y  ] 

<GCAL  [HUMAN  ?Y]»» 

Function  calls  are  enclosed  between  H<"  and  The  proof 

would  be  generated  by  asking  PLANNER  to  evaluate  the  expression: 

<GC AL  [FALLIBLE  TURING]> 

The  example  illustrates  several  points  about  PLANNER.  First, 
there  are  at  least  two  different  kinds  of  information  stored  in  the 
data  base:  declaratives  and  imperatives.  Notice  that  for  complex 
sentences  containing  quantifiers  or  logical  connectives  we  have  a 
choice  whether  to  express  the  sentence  by  declaratives  or  by 
imperatives. 

Second,  one  of  the  most  important  points  about  PLANNER  is  that 
it  is  ar  evaluator  for  statements.  It  accepts  input  in  the  form  of 
expressions  written  in  the  PLANNEB  language  and  evaluates  then, 
producing  a  value  and  side  effects.  ASSERT  is  a  function  which,  when 
evaloated,  stores  its  argument  in  the  data  base  of  assertions.  In 
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this  exaaple  we  have  defined  a  theorem  of  the  CONSEQUENT  type  [ we  will 
see  other  types  later].  This  states  that  if  ve  ever  want  to  establish 
a  goal  of  the  fora  [FALLIBLE  ?Y],  ve  can  do  this  by  accoaplishing  tha 
goal  [ HUBAN  ?Y  ],  vhere  T  is  an  identifier.  The  strange  prefix 
character  M?H  is  part  of  PLANNEE' s  pattern  aatching  capabilities 
[which  are  extensive  and  aake  use  of  the  pattern-natching  language 
HATCHLESS  vhich  is  explained  in  chapter  4  of  the  dissertation  ].  If  ve 
ask  PLANNEE  to  prove  a  goal  of  the  fora  [A  Y],  there  is  no  obvious  way 
of  knowing  whether  A  and  Y  are  constants  [like  TUBING  and  HUHAN  in  the 
exaaple]  or  identifiers.  LISP  solves  this  problea  by  using  the 
function  QUOTE  to  indicate  constants.  In  pattern  aatching  this  is 
inconvenient  and  nakes  *ost  patterns  auch  bulkier  and  aore  difficult 
to  read.  Instead,  PLANNEE  uses  the  opposite  convention  —  a  constant 
is  represented  by  the  atoa  itself,  while  an  identifier  aust  be 
indicated  by  adding  an  appropriate  prefix.  This  prefix  differs 
according  to  the  exact  use  of  the.  identifier  in  the  pattern,  but  for 
the  tine  being  let  us  just  accept  "?"  as  a  prefix  indicating  an 
identifier.  The  definition  of  the  tbeorea  indicates  that  it  has  one 
identifier,  I  by  the  [Y]  following  CONSEQUENT. 

•  •  4  *  The  third- stateaent  illustrates  the  function  GCAL,  which 

tries  to  prove  an  assertion.  This  can  function  in  several  way s.  If 
we  had  asked  PLANNEE  tc  evaluate  <GOAL  [HUHAH  TUBING ]>  it  would  have 
found  the  reguested  assertion  ianediately  in  the  data  base  and 
succeeded  [returning  as  its  value  soae  indicator  that  it  had 
succeeded].  However,  [FALLIBLE  TUBING]  has  not  been  asserted,  so  ve 
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aust  resort  to  theoreas  to  prove  it.  Later  we  will  see  that  a  GOAL 

stateaent  can  give  PLANNEE  various  kinds  of  advice  on  which  theoreas 
are  applicable  to  the  goal  and  should  be  tried.  Por  the  aoaent,  take 
the  default  case,  in  which  the  evaluator  tries  all  theoreas  whose 
conseguent  is  of  a  fora  which  matches  the  goal  [i.e.  a  theorem  aith  a 
consequent  [  ?Z  TOEING]  would  be  tried,  but  one  of  the  fora  [HAPPY  ?Z  ] 
or  [FALLIBLE  ?Y  ?Z  ]  would  not].  Assertions  can  have  an  arbitrary  list 
structure  for  their  fozaat  —  the;  are  not  United  to  two-aember  lists 
or  three-aeaber  lists  as  in  these  examples.  The  theorem  we  have  just 
defined  would  be  found,  and  in  trying  it,  the  natch  of  the  consequence 
to  the  goal  would  cause  the  identifier  Y  to  be  bound  to  the  constant 
TOEING.  Therefore,  the  theorea  sets  up  a  new  goal  [HORAN  TOEING]  and 
this  succeeds  iaaediatel;  since  it  is  in  the  data  base.  In  general, 
the  success  of  a  theorea  will  depend  on  evaluating  a  PLANNEE  progran 
of  arbitrary  complexity.  In  this  case  it  contains  only  a  single  GOAL 
statement,  so  its  success  causes  the  entire  theorea  to  succeed,  and 
the  goal  [FALLIBLE  TOEING]  is  proved.  The  following  is  the  protocol 
of  the  evaluation: 

<GOAL  [FALLIBLE  T0BIHGj>  [FALLIBLE  TOEING]  is  not  in  the  data  base 
so  attempt  to  inyoke  a  theorea  to  esablish  the  goal 
enter  THE0EEH1 
Y  becoaes  TOEING 

<GQAL  [HORAN  TOEING ]>  is  satisfied  since  tie  goal  is  in  the 
data  base 

return  [FALLIBLE  TOEING] 

The  way  in  which  identifiers  are  bound  by  Batching  is  of  key 
importance  to  FLANNBI.  Consider  the  question  "Is  anything  fallible?", 
or  in  logic  [EXISTS  X  [FALLIBLE  X]].  This  could  be  expressed  in 
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PLANNER  as: 

<PROG  [X]  <GOAL  [  FALLIBLE  ?X]» 

Notice  that  PROG  [PLANNER'S  equivalent  of  a  LISP  PROG]  in  this 
case  acts  as  an  existential  quantifier.  It  provides  a  binding-place 
for  the  identifier  X,  tut  does  not  initialize  it  —  it  leaves  it  in  a 
state  particularly  marled  as  unassigned.  To  answer  the  guesticn,  we 
ask  PLANNER  to  evaluate  the  entire  PROG  expression  above.  To  do  this 
it  starts  by  evaluating  the  GOAL  expression.  This  searcher,  the  data 
base  for  an  assertion  of  the  fora  [FALLIBLE  ?X  ]  and  fails.  It  then 
looks  for  a  theorem  with  a  consequent  of  that  form,  and  finds  the 
theorem  we  defined  above.  New  when  the  theorem  is  called,  the 
identifier  Y  in  the  theorem  is  linked  to  the  identifier  X  in  the  goal, 
but  since  X  has  no  value  yet,  Y  does  net  receive  a  value.  The  theorem 
then  sets  up  the  goal  [HUflAN  ?Y]  with  Y  as  an  identifier.  The  PLANNER 
primitive  GOAL  uses  the  data-base  retrieval  mechanism  i  look  for  any 
assertion  which  matches  that  pattern  [i.e.  an  instantiation],  and 
finds  the  assertion  [HONAN  TURING].  This  causes  Y  [and  therefore  X] 
to  be  bound  to  the  constant  TURING,  and  the  theorem  succeeds, 
completing  the  proof  and  returning  the  value  [FALLIBLE  TOEING]. 

There  seems  to  be  something  missing. •  So  far,  the  data  base 
has  contained  only  the  relevant  objects,  and  therefore  PLANNER  has 
found  the  right  assertions  immediately.  Consider  the  problem  we  would 
get  if  we  added  new  information  by  evaluating  the  statements: 

<ASSERT  [HDHAN  SOCRATES  ]> 

<ASSEHT  [GREEK  SOCRATES  ]> 
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Ouc  data  base  new  contains  the  assertions: 

[HUHAN  TUBING] 

[HUHA8  SOCRATES  ] 

[GREEK  SOCRATES] 
and  theorem!: 

<CON SEQUENT  [  Yj  [ FALLIBLE  ?T] 

<GOAl  rHDHAU  ?Y]» 

What  if  we  new  ask,  "Is  there  a  fallible  Greek?"  In  PLANNER  we 
would  do  this  by  evaluating  the  expression: 

<PROG  [X] 

<GOAI  [FALLIBLE  ?X]> 

<GOAL  [GREEK  ?X]» 

If  PLANNER  runs  into  a  failure  trying  to  evaluate  an  expression,  then 
it  backtracks  to  the  last  decision  that  was  wade  and  dunps  the 
responsibility  of  hew  to  proceed  on  the  procedure  which  aade  the 
decision.  Notice  what  light  happen.  The  first  GOAL  aay  be  satisfied 
by  exactly  the  saae  deduction  as  before,  since  we  have  not  removed 
inforaation.  If  the  data-base  retriever  happens  to  run  into  TOEING 
before  it  finds  SOCBATES,  the  goal  [HUHAN  ?I  ]  will  succeed,  binding  Y 
and  thus  X  to  TOEING.  After  [FALLIBLE  ?X]  succeeds,  the  PROG  will 
then  establish  the  new  goal  [ GREEK  TOEING  ],  which  is  dooaed  to  fail 
since  it  has  not  been  asserted,  and  there  are  no  applicable  theoreas. 
If  we  think  in  LISP  teras,  this  is  a  serious  problea,  since  the 
evaluation  of  the  first  GOAL  has  been  coapleted  before  the  second  one 
is  called,  and  the  "stack"  now  contains  only  the  return  address  for 
PROG  and  the  identifier  X.  If  we  try  to  go  back  to  the  beginning  and 
start  over,  it  will  again  find  TOEING  and  so  on,  ad  infinitua. 
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One  of  the  acst  important  features  of  the  PLANNEE  language  is 
that  backtracking  in  case  of  failure  is  always  possible,  and  aoreover 
this  backtracking  can  go  to  the  last  place  where  a  decision  of  any 
sort  w as  aade.  Here,  the  decision  was  to  pick  a  particular  assertion 
froa  the  data  base  to  aatch  a  goal.  Another  kind  of  decision  is  th< 
choice  of  a  theorea  to  try  to  achieve  a  goal.  PLANNER  keeps  enough 
inforaation  to  change  any  decision  and  send  evaluation  back  down  a  n* 
path. 

In  our  exaaple  the  decision  was  aade  inside  the  theorea  for 
FALLIBLE,  when  the  goal  [BOHAN  ?I  ]  was  Batched  co  the  assertion  [HOHAN 
TOEING].  PLANNEE  will  retrace  its  steps,  try  to  find  a  different 
assertion  which  Batches  the  goal,  find  [BOHAN  SOCfiATES  ],  and  continue 
with  the  proof.  The  theorea  will  succeed  with  the  value  [FALLIBLE 
SOCHATBS],  and  the  PEOG  will  proceed  to  the  next  expression,  <GOAL 
[GREEK  IX  ]>•  Since  X  has  been  bound  to  S0CBA1BS,  this  will  set  up  the 
goal  [GREEK  SOCBATBS ]  which  will  succeed  iaaediately  by  finding  the 
corresponding  assertion  in  the  data  base.  Since  there  are  no  *or-a 
expressions  in  the  PEOG,  it  will  succeed,  returning  as  its  valne  the 
value  of  the  last  expression,  [GBBEK  SOCBATBS].  The  whole  course  of 

the  deduction  process  depends  on  the  failure  nechanisa  for 

.  ■  •  ^ 

backtracking  and  trying  things  over  [this  is  actually  the  process  of 
trying  different  branches  down  the  conceptual  goal  tree.]  Thin  then  is 
the  PLAMNBB  executive  which  establishes  and  aanipulates  subgoals  in 
looking  for  a  proof. 

Be  would  now  like  to  give  a  soaewhat  aore  foraal  description 
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of  the  behavior  of  PLANNER  05  the  above  problea.  If  ve  intoduce 
suitable  notation  our  problea  solving  protocols  can  be  Bade  auch  aore 
succinct  and  their  structure  aade  visible.  Also  by  foraaliziag  che 
notions,  we  can  aake  PLANNER  construct  and  analyze  protocols.  This 
provides  one  kind  of  tool  by  which  PLANNER  can  understand  its  own 
behavior  and  aake  generalizations  on  how  to  proceed. 

In  this  case  the  protocol  is: 


1:  enter  PROG 

2:  X  is  rebound  but  not  initialized 

3:  <GOAL  [FALLIBLE  ?X ]>  will  atteapt  a  pattern  directed 
invocation  since  nothing  in  the  data  base  Batches  [FALLIBLE  ?X]. 

4:  enter  THB0BEB1 

5:  Batch  [FALLIBLE  ?Y]  with  [FALLIBLE  ?Z ]  thus  linkin' 

the  situation  is  shown  in  snapshot  nunber  1 

6:  <GOAL  [BOHAN  ?!]>  finds  [BOHAN  TOEING ]  in  the  da' 

base 

7:  y  gets  the  value  TORINO  thus  giving  X  the  va. 
TARING 

3:  return  [HOHAN  TORIHG  ] 

9:  TBECREH1  returns  [FALLIBLE  TOEING  ] 

10:  <GOAL  [ GREEK  TOEING  ]>  fails  since  if  is  not  la  the  data  base 
and  there  are  ao  Matching  consequents 

Thus  PLANNER  aust  backtrack  to  step  7  and  try  again.  The  situation  is 
shown  in  snapshot  nuaber  2.  For  the  convenience  of  the  reader,  ve 
will  repeat  the  first  six  steps  froa  above  and  then  continue  the 
protocol. 


1:  enter  PROG 

2:  X  is  rebound  but  not  initialized 
3:  <GQAL  [FALLIBLE  ?X]> 

4:  enter  THEORER1 

5:  aatch  [FALLIBLE  71 ]  with  [FALLIBLE  ?X  ]  thus  linking  T  to  X 
6':  <GOAL  [BOHAN  ?Y]>  finds  [HOHAN  SOCRATES]  ia  the  data 
base 

11r  Y  gets  the  value  SOCRATES  thrs  giving  X  the  value 
SOCRATES 

12:  return  [FALLIBLE  SOCRATES] 


3 .  p 


FORMAT  OF  FUNCTION  ACTIVATIONS 
IN  SNAPSHOTS 


IDENTIFIER-  BINDINGS 


NEW 

IDENTIFIER 


,  BINDINGS  I 

L _ _ _ _ _ l 


BACK 
TRACK 
CONTr  . 


NOTE  :  THE  IDENTIFIER -BINDINGS  AND 

RETURN  -  CONTROL  POINTERS  OF  AN 
ACTIVATION  ARE  USUALLY  THE  SAME 
AND  THUS  ARE  COMBINED  INTO  A 
DOUBLE  POINTER  LIKE  THIS  ==► 


SNAPSHOT  OF  EVALUATION  OF 


/ 


SNAPSHOT 


SNAPSHOT  NO. 


<  GOAL  [HUMAN  ?Y]» 


SNAPSHOT 


<  GOAL  [  HUMAN?  Y]» 
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13:  TfiEOREH  1  returns  [  FALLIBLE  SOCRATES  ] 

14:  <GO AL  [GREEK  SOCRATES]> 

15:  return  [GREEK  SOCRATES]  as  the  top  level  value 

The  situation  is  shown  in  snapshot  nuaber  3. 

So  far  we  have  seen  that  although  PLANNER  is  written  as  an 
evaluator,  it  differs  in  several  critical  ways  froa  anything  which  is 
normally  considered  a  prograaaing  langua/e.  First,  it  is  goal- 
directed.  Theorems  can  be  thought  of  as  subroutines,  but  they  can  be 
called  by  specifying  the  goal  which  is  to  be  satisfied.  This  is  like 
having  the  abilitiy  to  say  "Call  a  subroutine  which  will  achieve  the 
desired  result  at  this  point."  Second,  the  evaluator  has  the 
mechanism  of  success  and  failure  to  handle  the  exploration  of  the 
conceptual  goal  tree.  In  PLASHES  there  is  no  explicit  goal  tree.  The 
conceptual  goal  tree  is  represented  by  a  SNAPSHOT  of  a  CONFIGURATION 
of  PROCESSES.  Thus  PLANNER  has  powerful  control  structure  primitives 
to  allow  the  conceptional  goal  structure  to  be  easily  and  naturally 
reflected  in  the  execution  of  PLANNER  processes,  ether  evaluators, 
such  as  LISP,  with  a  basic  recursive  evaluator  have  no  way  to  do  this. 
One  of  our  current  areas  of  research  is  to  increase  the  richness  of 
the  machinery  provided  by  PLANNER  to  guide  the  movement  to  the  gc-ai  - 
Third,  PLANNER  contains  a  large  set  of  primitive  commands  for  matching 
patterns  and  manipulating  a  data  base,  and  for  handling  that  data  base 
efficiently. 

On  the  other  side,  we  can  ask  how  it  differs  from  other 
theorem  provers.  Hkat  is  gained  by  writing  theorems  in  the  fora  of 
programs,  and  giving  them  power  to  call  other  programs  wmch 
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manipulate  data?  The  Key  is  in  the  for*  of  the  data  the  theorem- 
provet  can  accept.  Host  systems  take  declarative  information,  as  in 
predicate  calculus.  This  is  in  the  fora  of  expressions  which 
represent  "facts'*  about  the  world.  These  are  manipulated  by  the 
theorem- prover  according  to  soao  fixed  unifora  process  set  by  the 
systea.  PLANHEB  can  make  use  of  imperative  information,  telling  it 
how  to  go  about  proving  a  subgoal,  or  to  sake  use  of  an  assertion. 

This  produces  what  is  called  UIEBABCBICAL  control  structure.  That  is, 
any  theorem  can  indicate  what  the  theorem  prover  is  supposed  to  do  as 
it  continues  the  proof.  It  has  the  full  power  to  evaluate  expressions 
which  can  depend  on  both  the  data  base  and  the  subgoal  tree,  and  to 
use  its  results  to  control  the  further  proof  by  making  assertions, 
deciding  what  theorems  are  to  be  used,  and  specifying  a  seguence  of 
steps  to  be  followed.  Mhat  does  this  mean  in  practical  terms?  In 
what  way  does  it  make  a  "better"  theorem  prover?  Be  will  give  several 
examples  of  areas  where  the  approach  is  important. 

First,  consider  the  basic  problem  of  deciding  what  subgoals  to 
try  in  attempting  to  satisfy  a  goal,  fery  often,  knowledge  of  the 
subject  matter  will  tela,  us  that  certain  methods  are  very  likely  to 
succeed,  others  may  be  useful  if  certain  other  conditions  are  presort, 
while  others  may  be  possibly  valuable,  but  not  likely.  Be  would  like 
to  have  the  ability  to  use  heuristic  programs  to  determine  these  facts 
and  direct  the  theorem  prover  accordingly.  It  should  be  able  to 
direct  the  search  for  goals  cmd  solutions  in  the  best  *ay  possible, 
mad  be  able  to  bring  as  such  intelligence  as  possible  to  bear  on  the 
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decision.  In  FLASHES  this  is  done  by  adding  to  oar  GOAL  stateaent  a 
recoaaendation  list  vhich  can  specify  that  ORLY  certain  theoreas  are 
to  be  tried,  or  that  certain  ones  are  to  be  tried  FIRST  in  a  specified 
order.  Since  theoreas  are  programs,  subroutines  of  any  type  cun  be 
called  to  help  sake  this  decision  before  establishing  a  new  GOAL. 

Each  theorem  has  a  naae  [in  our  definition  on  page  1,  the  theorea  was 
given  the  naae  THEOBEH 1  ],  to  facilitate  referring  to  then  explicitly. 

Another  iaportant  problen  is  that  of  aaintaining  a  data  base  with 
a  reasonable  aacunt  of  aaterial.  Consider  the  first  example  above. 

The  stateaent  that  all  huaans  are  fallible,  while  unaabiguous  in  a 
declarative  sense  is  actually  aabiguous  in  its  iaperative  sense  [i.e. 
the  way  it  is  to  be  used  by  the  theorea  prover].  The  first  way  is  to 
sioply  use  it  whenever  we  ace  faced  with  the  need  to  prove  [FALLIBLE 
?X  ].  Another  w  r.j  wight  be  to  watch  for  a  stateaent  of  the  forn 
[HUHAN  ?XJ  to  be  asserted,  and  to  iaaediately  assert  [FALLIBLE  ?X]  as 
well.  There  is  no  abstract  logical  difference,  but  the  iapact  on  the 
data  base  is  treaendous.  The  wore  conclusions  we  draw  when 
inforaation  is  asserted,  the  easier  proofs  will  be,  since  they  will 
not  have  to  aake  the  additional  steps  to  deduce  these  consequences 
over  and  over  again.  However  since  we  don’t  have  infinite  speed  and 
size,  it  is  clearly  folly  to  think  of  deducing  and  asserting 
everything  possible  [or  even  everything  interesting]  about  tbe  data 
when  it  is  entered.  If  we  sere  working  with  totally  abstract 
aeaningless  theoreas  and  axions  [an  assuaption  which  would  not  be 
incompatible  with  many  theorea* pro ring  scheaes],  this  would  be  an 
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insoluble  dileaaa.  But  PLASHES  is  designed  to  work  in  the  real  world, 
where  our  knowledge  is  auch  aore  structured  than  a  set  of  axioas  and 
rules  of  inference.  He  aay  very  well,  when  we  assert  [ LIKES  ?X 
POETBX]  want  to  deduce  and  assert  [HOflAS  ?X],  since  in  deducing  things 
about  an  object,  it  will  very  often  be  relevant  whether  that  object  is 
hunar,  and  we  shouldn’t  need  to  deduce  it  each  tiae.  On  the  other 
hand,  it  would  be  silly  to  assert  [ HAS- AS-PABT  ?X  SPLEBN],  since  there 
is  a  horde  of  facts  equally  iaportant  and  equally  limited  in  use. 

Part  of  the  knowledge  which  PLAHNEB  should  have  of  a  subject,  then,  is 
what  facts  are  iaportant,  and  when  to  draw  consequences  of  an 
assertion.  This  is  dene  by  having  theoreas  of  an  antecedent  type: 

‘  <ASS£RT  <D Ef  IN E  THE0HEH2 

ANTECEDENT  [X  Y]  [LIKES  ?X  ?Y] 

<ASSERT  [  HONAN  ?X]»» 

This  says  that  when  we  assert  that  X  likes  soaething,  we 
should  also  assert  [HUHAN  ?X  ].  Of  course,  such  theoreas  do  not  have  to 
be  so  siaple.  A  fully  general  PLASHES  prograa  can  be  activated  by  an 
ANTECEDEHT  theorei,  doing  an  arbitrary  [that  is,  the  progranier 
whether  he  be  aan  or  aachine  has  free  choice]  aaount  of  deduction, 
assertion,  etc.  Knowledge  of  what  we  are  doing  in  a  particular 
problea  aay  indicate  that  it  is  soietiaes  a  good  idea  to  do  this  kind 
of  deduction,  and  other  tiaes  not.  As  with  the  CONSEQUENT  theoreas, 
PLAINER  has  the  full  capacity  when  soaething  is  asserted,  to  evaluate 
the  current  state  of  the  data  and  proof,  and  specifically  decide  which 
ANTECEDEHT  tbeorear.  should  be  called. 

PLANNEE  therefore  allows  deductions  to  use  all  sorts  of 
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knowledge  about  the  subject  natter  which  go  far  beyond  the  set  of 
axioas  and  basic  deductive  rules.  PLAHHEB  itself  is  subject- 
independent,  but  its  power  is  such  that  the  deduction  process  never 
needs  to  operate  on  such  a  level  of  ignorance.  The  progranaer  can  put 
in  as  much  heuristic  knowledge  as  he  wants  to  about  the  subject,  just 
as  a  good  teacher  would  help  a  class  to  understand  a  aatheaatical 
theory,  rather  than  just  telling  cher  the  axioas  and  then  giving 
theoreas  to  prove. 

Another  advantage  in  representing  knowledge  in  an  imperative 
fora  is  the  use  of  a  theorem  prover  in  dealing  with  processes 
involving  a  sequence  of  events.  Consider  the  case  of  a  robot 
aani pula ting  blocks  on  a  table.  It  aight  have  data  of  the  fora, 
"blockl  is  on  block2,"  "blcck2  is  behind  block3",  and  "if  x  is  on  y 
and  you  put  it  on  z,  then  x  is  on  z,  and  is  no  longer  on  y  unless  y  is 
the  sane  as  z".  Hany  examples  in  papers  on  theorea  provers  are  of 
this  fora  [for  exaaple  the  classic  "aonkey  and  bananas"  problea].  The 
problea  is  that  a  declarative  theorem  prover  cannot  accept  a  statement 
like  £  OH  B 1  B2  ]  at  face  value.  It  clearly  is  not  an  axiom  of  the 
system,  since  its  validity  will  change  as  the  procass  goes  on.  It 
usually  is  put  in  a  fora  [OH  B1  B2  SO]  where  SO  is  a  symbol  for  an 
initial  state  of  the  world.  The  third  statement  might  be  expressed 
as: 

[FOB- ALL  TOPBLOCK  NEiSUPPOHT  CLDSUPPOBT  S 
[AMD 

[OH  TOPBLOCK  MEWSUPPOBT  [POT  TOPBLCCK  HEIS0PPOHT  S]] 
[OS 


[EQUAL  HESSUPPCBT  OLDSUPPOET] 
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[NOT  [CN 

TOPBLCCK 

OLDSUPFORT 

[PUT  TCPBLOCK  NEWSUPPORT  S  ]  ]  ]  ] ] ] 

In  this  representation,  [PUT  X  K  S]  is  the  state  which  results 
from  putting  X  on  Y  when  the  previous  state  was  S.  We  run  into  a 
problem  when  we  try  to  ask  [CN  Z  H  [PUT  X  Y  £]]  i.e.  is  block  Z  on 
block  B  after  we  put  X  on  Y?  A  human  knows  that  if  we  haven’t  touched 
Z  or  W  we  could  just  ask  [ON  Z  W  S]  but  in  general  it  may  take  a 
complex  deduction  to  decide  whether  we  have  actually  moved  them,  and 
even  if  we  haven’t,  it  will  take  a  whole  chain  of  deductions  [tracing 
back  through  the  time  sequence]  to  prove  they  haven’t  been  moved.  In 
PLANNER,  where  we  specify  a  process  directly,  this  whole  type  of 
problem  can  be  handled  in  an  intuitively  more  satisfactory  way  by 
using  the  primitive  function  ERASE. 

Evaluating  < ER ASE  [CN  ?X  ?Y  ]>  removes  the  assertion  [ON  ?X  ?Y] 
from  the  data  base.  If  we  think  of  theorem  provers  as  working  with  a 
set  of  axioms,  it  seems  strange  to  have  function  whose  purpose  is  to 
erase  axioms.  If  instead  we  think  of  the  data  base  as  the  ’’state  of 
the  world"  and  the  operation  of  the  prover  as  manipulating  that  state, 
it  allows  us  to  make  great  simplifications.  Now  we  can  simply  assert 
[ON  B 1  B2]  without  any  explicit  mention  of  states.  Be  can  express  the 
necessary  theorem  as: 

<ASSEBT  <DEFINI  THE0REH3 

CCCNSECUENT  r TCPBLOCK  NEHSDPPCBT  OLDSUPPOBT] 

[PUT  7TOPELOCK  7NEWSUPPOBT] 

<GOAL  [ON  7T0PBL0CK  7CLDSUPPCBT ]> 

<EBASE  [ON  7T0PBL0CK  7CLDSUPP0BT  ]> 

<ASSBBI  [ON  7TCPBL0CK  7MEBSUFPOBT ]»» 
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This  says  that  whenever  we  want  to  satisfy  a  goal  of  the  fcra 
[POT  7T0PBL0CK  7NENSUPP0RT  ],  we  should  first  find  out  what  thing 
CLDSUPPOBT  the  thing  TCPBLOCK  is  sitting  on,  erase  the  Zact  that  it  is 
sitting  on  OLDSUPPOBT,  and  assert  that  it  is  sitting  cn  NEWSUPPORT. 

We  could  also  do  a  number  of  other  things,  such  as  proving  that  it  is 
indeed  possible  to  put  TOPELCCK  on  NEWSUPPORT,  or  adding  a  list  of 
specific  instructions  to  a  movement  plan  for  an  ara  to  actually 
execute  the  goal.  In  a  more  complex  case,  other  interactions  night  be 
involved.  For  ex--  .pie,  if  we  are  keeping  assertions  of  the  fora 
[ABOVE  ?X  ?Y  ]  we  would  need  to  delete  those  assertions  which  becaae 
false  when  we  erased  [CN  ?X  ?Z j  and  add  those  which  becaae  true  when 
we  added  [ON  ?\  ?I  ].  ANTECEDENT  theoreas  would  be  called  by  the 
assertion  [ON  ?X  ?Y]  to  take  care  of  that  part,  and  a  similar  group 
called  ERASING  theoreas  can  be  called  in  an  exactly  analogous  way  when 
an  assertion  is  erased,  to  derive  consequences  of  the  erasure.  Again 
we  eaphasize  that  which  of  such  theoreas  would  be  called  is  dependent 
on  the  way  the  data  base  is  structured,  and  is  determined  by  knowledge 
of  the  subject  natter.  In  this  example,  we  would  have  to  decide 
whether  it  was  worth  adding  all  of  the  ABOVE  relations  to  the  data 
base,  with  the  resultant  need  to  check  then  whenever  soaething  is 
aoved,  or  instead  to  cait  thea  and  take  tine  to  deduce  then  frca  the 
ON  relation  each  tine  they  are  needed. 

Thus  in  PLANNEE,  the  changing  state  of  the  world  can  be 
airrored  in  the  changing  state  of  the  data  base,  avoiding  any  need  to 
aake  explicit  aention  of  states,  with  the  requisite  overhead  of 
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deductions.  This  is  possible  since  the  information  is  given  in  an 
imperative  form,  specifying  theorems  as  a  series  of  specific  steps  to 
be  executed.  PLANNEB  also  allows  the  construction  of  local  data  bases 
called  states  which  are  variants  of  the  global  data  base.  Evaluation 
of  PLANNEB  expressions  is  carried  out  relative  to  a  local  state.  Thus 
simultaneous  consideration  can  be  given  to  two  incompatible  states  of 
the  world  by  explicitly  calling  the  evaluator  to  evaluate  statements 
in  the  tvo  states. 

If  we  look  back  to  the  distinction  between  assertions  and 
theorems  made  at  the  beginning  of  this  chapter,  it  would  seen  that  we 
have  established  that  the  base  of  assertions  is  the  "current  state  of 
the  world",  while  the  base  of  theorems  is  our  permanent  knowledge  of 
how  to  deduce  things  from  that  state.  This  is  not  exactly  true,  and 
one  of  the  most  exciting  possibilities  in  PLANHEB  is  the  capability 
for  the  program  itself  to  create  and  modify  the  PIANRES  functions 
which  make  up  the  theorem  base.  Bather  than  simply  making  assertions, 
a  particular  PLANNER  function  night  be  written  to  put  together  a  new 
theorem  or  make  changes  to  an  existing  theorem,  in  a  way  dependent  on 
the  data  and  current  knowledge.  It  seems  likely  that  meaningful 
"teaching"  involves  this  type  of  behavior  rather  than  simply  modifying 
parameters  or  adding  nore  individual  facts  [assertions]  to  a 
declarative  data  base. 

For  example  suppose  we  are  given  the  following  protocols  for  a 
function  f.  An  expression  such  as  "new  [5  *  4]"  means  that  we  are 
introducing  a  new  identifier  which  is  5  *  4  =  20. 
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<f  C>  :  0=0  IS  TBOE  SO  1 
Thus  <£  0>  =  1 


The  above  expression  reads,  "to  coapute  <f  0>  you  test  0=0 
which  is  true  sc  the  answer  is  1". 


<£  1>  :  1=0  IS  FALSE  SO 

1  *  new  [1-1]  0=0  IS  TBUE  SO  1 

Thus  <f  1>  =  1 

The  above  expression  reads,  "to  coapute  <f  1>  you  test  1=0 
which  is  false  so  the  answer  is  1  tines  the  guantity  which  is  coaputed 
by  first  coaputing  the  interaediate  result  1-1  then  testing  if  0=0 
which  is  true  so  the  guantity  is  1." 

<f  2>  :  2=0  IS  FALSE  SO 

2  *  new  [2-1]  1=0  IS  FALSE  SO 

1  *  new  [1-1]  0=0  IS  TBOE  SO  1 

Thus  <f  2>  =  2  *  1  ♦  1  =  2 


<f  3>  :  3=0  IS  PALSE  SO 

3  *  new  [3-1]  2=0  IS  FALSE  SO 

2  *  new  [2-1]  1=0  IS  FALSE  SC 

1  *  new  [1-1]  0=0  IS  TR0E  SO  1 
Thus  <f  3>  =  3  *  2  ♦  1  *  1  *  6 


By  the  process  of  "variab  iization",  we  conclude  that  the 
above  protocols  are  coapatible  with  the  following  prograa  which  is  in 
the  fora  of  a  tree  [which  we  shall  call  the  protocol  tree]. 


<f  x0>  =  if  x  C=  0  then  1 

else  xO  *  new  [[x0-1]=x1]  if  x1=0  then  1 

else  xl  ♦  new  [[x1-1]=x2]  if  x2=0  then  1 
else  x2  ♦  new  [[x2-1]=x3] 
if  x3=0  then  1 
e 1 se ... 


Bow  by  identifying  indistinguishable  nodes  on  the  protocol  tree,  we 


<f  x>  -  if  x=0  then  1 

else  x  *<f  [x-1]> 


obtain: 
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The  reader  will  note  that  f  is  the  factorial  function,  PLAHISH 

procedures  and  theorems  can  be  taught  in  precisely  the  sane  fashion 
[which  we  call  procedural  abstraction].  For  example,  the  computer  can 
be  taught  to  build  a  wall  or  recognize  a  tower  froa  examples.  The 
reader  is  cautioned  that  although  we  shall  speak  of  the  coupnter  being 
"taught",  we  do  not  assume  that  anything  like  what  has  been 
classically  described  as  "learning"  is  taking  place.  He  assume  that 
the  teacher  has  a  good  working  model  of  the  student  that  is  being 
taught  and  that  be  honestly  attempts  to  convey  a  certain  body  of 
knowledge  to  the  student,  of  course  the  student  will  be  told  anything 
which  might  help  him  to  understand  the  material  faster. 

Procedural  abstraction  is  one  way  in  which  a  special  purpose 
routine  can  be  constructed  from  general  goal  oriented  language.  He 
would  like  to  express  the  intended  properties  of  the  special  purpose 
routine  so  that  we  can  establish  that  the  routine  really  does  what  it 
is  supposed  to  do.  For  exaaple  we  might  be  interested  in  establishing 
that  the  function  divide  defined  below  satisfies  its  intentions. 


<define  divide  <fmnction  idivide 

;"let  idivide  be  name  of  this  activation" 

[n  d] 

;"the  function  divide  is  a  function  of  two  arg  iments  n  and  d" 
<repeat  [£r  .n]  [g  0]] 

; "initialize  r  to  n  and  g  to  zero” 

;"we  are  in  a  repeat  loop  which  will  repeatedly 
execute  the  following  expressions” 

<cond 

[<is?  <less  .d>  .r) 

;*if  .r  is  less  than  .d  then" 

<. idivide  .g  . r> 

;”exit  the  activation  named 

idivide  with  .g  mad  .r"]> 

<mssign  : r  <-  .r  .d>> 
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;"assign  r  the  value  of  r  ninus  dn 
<assign  :  q  <+  .q  1» 

; "assign  g  the  value  of  g  plus  1" 

;*now  go  back  and  do  the  body  of  the  repeat 
loop  all  over  again"»> 

Me  shall  express  the  intentions  of  the  function  DIVIDE  in  a 
goal  oriented  formalism  called  INTENDEB.  INTEBDEB  enables  os  to  eaned 
the  intentions  for  a  prograa  in  the  text  of  the  program.  The  easiest 
way  to  understand  IHTBKDER  is  to  watch  how  it  works.  In  order  to 
show  hov  it  works  we  must  first  define  some  intentions.  INTEBDEB 
introduces  two  new  primitives  CVEBALL  and  IHTEHT  to  express  intentions 
in  code.  The  printive  GVEBALL  expresses  the  overall  intention  of  a 
function  or  loop  whereas  IMTEhT  asserts  that  the  intended  situation 
really  holds  within  the  body  of  the  function  or  loop.  The  meaning  of 
the  intentions  embedded  in  the  function  DIVIDE  are  explained  below. 
INTENDEB  is  a  giant  sledge  haaaer  to  use  to  sguash  such  a  tiny 
problea.  The  reader  can  see  this  sledge  haaaer  used  on  harder 
problems  in  chapter  7.  INTEBDEB  needs  to  be  able  to  talk  about 
function  calls  in  a  pattern  directed  way.  He  will  use  !*  to  suppress 
procedural  invocations.  Thus  whereas  <♦  3  5>  evaluates  to  the  HUHBER 
8,  the  expression  !•<♦  3  5>  will  evaluate  to  the  CALL  <♦  3  5>. 
Assertions  which  contain  calls  constitute  a  still  higher  level 
assertion  than  the  two  which  we  have  introduced  thus  far.  The 
semantics  of  v  assertions  are  determined  in  part  by  the  body  of  the 
procedure  wh'^  r  led.  For  example  the  assertion  that  !*<=  !•<♦  1 
2>  1  '<♦  2  1>>  can  established  from  the  DEFINITION  of  ♦.  Similarly 

in  a  very  incestuous  way,  we  can  make  assertions  about  PLAHREB 
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procedures  whose  intentions  are  tLenselves  written  in  PLABHEB  and  at 
any  given  tiae  constitute  the  aodel  that  PLANNER  has  of  itself!  By 
using  intentions  expressed  in  PliHNEB,  there  is  nothing  that  in 
principle  PLASSEB  cannot  be  aade  to  understand  about  itself. 


<define  divide  <f unction  idivide  [n  d] 

<overall  [  ] 

<intention  [  ] 

<and 

<goal  l*<is  !*<greater  0>  .n» 

<goal  !'<is  !*<greater  0>  .d»> 

<and 

<assert  !'<is  !*<greater  0>  ,n» 

<assert  !*<is  !*<greater  0>  .d»» 

<repeat  [[r  .n]  [g  0]] 

! ;<intention 

<goal  !•<=  .n  !*<♦  .r  !•<*  .d  ,g»» 

<assert  !*<=  .n  !•<♦  .c  !’<♦  .d  .g»»> 

<cond 

[<is?  <less  .d>  .r> 

<. idivide  .g  ,r>]> 

<assign  :r  <-  .r  .d>> 

<assign  :g  <>  .g  1>» 

<f unction  [C  B] 

<intention  [ ] 

<and 

<assert  !•<*=  ,n  !  •<♦  ,B  !•<*  .d  .Q»» 
<assert  !*<i.s?  !*<less  ed>  .B>» 

<and 

<goal  !•<=  .n  !«<♦  .5  !•<*  .d  .Q»» 

<goal  !»<is?  !"<less  .d>  .H>;>»»» 

The  overall  intention  for  the  function  DIVIDE  is  that  it  return  two 

values  Q  and  B  which  we  assert  will  have  the  property  that 


!'<=.n  !•<♦  .B  l»<*  .d  •  Q>» 

The  inside  intent  of  the  function  DIVIDE  is  the  goal  that  DIVIDE  will 
return  two  values  Q  and  B  which  will  have  the  property  that 


I #<«.n  l'<+  ,B  !•<*  .d  •  Q»> 
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The  body  of  DIVIDE  is  a  HE PE IT  loop  with  two  locals  r  and  g  which  are 
respectively  initialized  to  0  and  n.  The  overall  intention  of  the 
REPEAT  loop  is  the  goal 


!•<=  .n  !•<♦  .r  !«<*  »d  .  q» > 

The  REPEAT  loop  has  an  intent  that  asserts  that 


!»<=.n  !•<♦  .r  !*<*  .d  .g»> 
at  the  top  of  the  loop. 

The  intentions  for  DIVIDE  are  proved  by  running  then  in 
INTENDEB.  The  intentions  are  verified  abstractly.  Thos  they  aust  be 
true  independent  of  what  the  actual  argunents  to  the  function  are.  He 
shall  use  .he  notation  r_n  for  the  nth  value  of  the  identifier  *  with 
being  an  abbreviation  for  the  initial  value  of  x.  The  actions  of 
IHTEHDEB  on  the  intentions  of  DIVIDE  are  as  follows: 


Proa  the  overall  all  intentiion  of  the  function  we  have: 
<assert  !*<is  !*<greater  0>  n_>> 

<assert  !'<is  l'<greater  0>  d_» 

The  following  assertions  coae  fron  the  declarations  of  the 
a peat  loop 

< assert  •<*  r_  n__>> 

<assert  *<-  q_  0» 

The  intention  of  the  repeat  statement  on  first  entry  is 
sat  w;ied: 

<goal  !c<= 
n 

!“•<♦ 

r 

|T<*  a_  g_»» 

We  inductively  assune  for  the  repeat  loop 
< a 83 art  I  •<* 
n 

!”<♦ 


1.  page  58 


r  1 

!•<♦  d_  q_1»>> 

enter  intention*-  of  COHD 

There  are  two  c^ses  for  the  conditional: 


Case  1 : 

<assert  !*<is? 

! *  <less  d  > 
r_1>> 

From  the  overall  intention  we  have: 
Q  becoaes  q_1 

B  becocoaes  t_1 
<goal  ! ' <= 
n_ 

!  *  <♦ 

r  1 

!*<*  d_  g_1»» 

<goal  !*<is?  !*<les3  d_>  r_1» 


Case2: 

<assert  !*<is? 

!'<greater*  d  > 
r  1>> 


Proa  <assign  :r  <-  .r  .d»  we  get: 
<assert  ! *  <= 

r  2 

!•<-  r  1  d  »> 


Froa  <assiqn  :g  <♦  .  g  1»  we  get: 
<assert  !«<= 

9-2 

!•<♦  g_l  1»> 


The  recursive  goal  is  satisfied  by  siaplif ication: 
<goal  !•<=  r 

n 

!7<* 

r  2 

l7<*  d_  q_2»>> 
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4.  THE  PATTERN  BATCHING  LANGUAGE  H ATC  HESS 


HATCHLESS  is  a  pattern  directed  language  that  is  used  in  the 
iaplenentation  of  PLANNER.  HATCHLESS  is  used  both  in  the  internal 
workings  of  PLANNER  and  as  a  tool  in  the  deductive  systea  itself. 
HATCHLESS  is  similar  in  certain  respects  to  other  structural  pattern 
matching  languages  such  as  CONVERT  and  SNOBOL.  It  has  been  designed 
with  the  following  considerations  in  Bind: 

0.  The  language  aust  obey  the  Fundaaental  Principle  of  Pattern 
Directed  Computation:  the  procedure  body  should  be  a  pattern  that 
describes  the  purpose  of  the  procedure.  The  principle  has  been 
developed  even  further  in  PLANNER  where  procedures  are  invoked  on  the 
basis  of  their  intent. 

1.  The  language  should  be  very  powerful  yet  siaple  constructs 
should  be  efficiently  compiled.  By  incorporating  wore  knowledge  into 
a  prograa,  it  Bust  be  possible  to  increase  its  efficiency  up  to  the 
Units  iaposed  by  the  aachine  on  which  it  runs. 

2.  Functions  aust  be  able  to  be  separately  coapiled. 

3.  It  should  not  require  parsing  for  efficient 
interpretation.  Procedures  should  be  naturally  and  efficiently 
constructed  and  edited  by  ether  procedures. 

4.  The  language  aust  interface  with  PLANNER  in  a  natural  way 
sine  a  it  is  used  as  a  basic  part  of  the  deductive  systea.  Effective 
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problem  solving  requires  a  sophisticated  prcgraacable  catcher. 

5.  The  language  should  treat  strings,  lists,  vectors,  tuples., 
and  nodes  sycaetrically  so  that  for  the  cost  part  the  sa.ce  prograa 
will  run  whether  the  structures  are  cade  up  of  vectors,  tuples,  nodes, 
or  lists.  Declarations  determine  which  fore  is  actually  used. 

6.  The  language  should  have  no  automatic  coercion.  Any 
procedures  which  wish  to  coerce  their  arguments  should  he  able  to  do 
so  easily. 

7.  The  language  should  have  only  one  code  of  evaluation  for 
value.  Locatives  should  always  be  generated  explicitly  in  the  sace 
way. 

8.  All  the  loops  of  the  language  should  be  guaranteed  to  be 
properly  nested. 
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4.1  The  Syntax  of  Identifiers  and  Expressions 


fUTCHLESS  attempts  to  obey  the  Fundamental  Principle  of 
Pattern  Directed  Coaputation:  the  procedure  body  should  be  a  pattern 
of  vhat  the  procedure  is  supposed  to  accosplish.  For  exaaple  it 
allows  the  list  (a  b  c)  to  be  produced  by  siaply  evaluating  (a  b  c)  . 
In  atteapting  to  realize  the  principle  we  have  been  led  to  develop  a 
certain  amount  of  syntax  which  (unfortunately!)  aust  be  described. 

4.1.1  Prefix  Operators  for  Identifiers 

is  is  usual  in  pattern  Batching  languages  we  shall  allow 
constants  like  3,  a,  (a  b) ,  and  (e  (f  g) )  to  Batch  only  thenselves. 
in  identifier  is  indicated  by  a  prefix  operator  which  tells  how  the 
identifier  is  to  be  used.  For  exaaple  .x  is  the  element  value  of  the 

identifier  x.  It  x  has  the  value  (a  3)  then  .x  will  oaly  teb  (a  3). 

Ve  need  to  be  able  to  change  the  value  of  an  identifier  in  a  pattern 
natch.  Suppose  that  x  has  the  valne  3.  If  we  natch  _x  [the 
tentative  value  of  x]  against-  (a  b)  e  then  x  is  given  the  value  (a  b)  • 

The  identifier  x  will  keep  the  value  (a  b)  if  the  reaainder  of  the- 

pattern  Batches.  Otherwise  the  value  of  x  will  revert  to  3.  Again 
suppose  that  x  has  tl*!  value  3.  If  we  Batch  :x  [the  altered  ralne  of 
x]  against  {a  b) ,  then  x  is  given  the  value  (a  b).  However  the  value 
of  x  will  remain  (a  b)  whether  or  not  the  ren&inder  of  the  pattern 
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matches. 

The  above  prefix  operators  are  actually  defined  in  terms  of 
procedure  calls.  Be  are  not  enamored  with  the  syntax  of  the  prefix 
operators  but  they  are  easier  to  type  than  the  procedores  listed 
below. 

A  small  meta  syntax  is  needed  in  order  to  give  explanations  of 
the  primitives  of  the  language.  He  shall  use  i  to  delimit 
metasyntatic  variables  which  are  elements  and  -  to  delimit  those  which 
are  sequences. 

The  following  table  explains  the  prefix  operators  which  yield 
element  values: 

•ixl  =  < VALUE  |x|>  the  element  value  of  the  identifier  1 x ] 

,1x1  =  <GLOB AL  1 x ] >  the  element  global  value  of  ]x| 


The  following  table  explains  the  prefix  operators  which  match 
elements: 

?lxj  =  <GI TER  l x 1 >  will  give  )x]  the  value  of  the  matching 
element  if  JxJ  does  not  already  have  a  value;  otherwise  ?lxl  will  only 
match  the  value  of  J x  J . 

: ] x 1  =  <ALTEB!-PEBSIS!EHT  ] x ) >  will  alter  the  value  of  x  to  be 
the  matching  element  even  if  JxJ  already  has  a  value. 

_Jx|  *  <AL?EB I-TEMT1TIVE  |xj>  will  tentatively  alter  the  value 
of  ] x |  to  be  the  matching  element  but  if  a  failure  backs  up  then  the 
old  value  of  J  x |  will  he  restored. 


If  x  has  the  value  {a  1)  then  (b  .x  4)  will  evaluate  to/  (b  (a 

’< 

1)  4).  The  character  !  is  the  esco  character.  Ke  will  use  !.x  to 

t 

I 

denote  the  segaent  value  of  the  identifier  x.  For  example  (b  l  lx  4) 

1 

i 

will  evaluate  to  (b  a  1  4) .  In  each  case  preceding  the  prefix ' 
operator  for  an  identifier  will  result  in  the  segaent  prefix  operator 
for  that  identifier.  If  we  latch  the  pattern  (c  !:x  d)  against  the 
value  (c  3  a  d)  then  x  will  be  given  (3  a)  as  its  value. 

The  following  table  explains  the  prefix  operators  which  yield 
segment  values: 

l.jxi  =  {VALUE  | x 1 }  the  segaent  value  of  the  identifier  |x| 

! , | x |  =  (GLOBAL  lx|)  the  segaent  global  value  of  |x] 


The  following  table  explains  the  prefix  operators  which  natch 
segaents: 

!'? J x  1  s  (GIVEN  x]  will  give  x  the  value  of  the  latching 
segaent  if  x  does  not  already  have  a  value;  otherwise  !?x  will  only 
Batch  the  value  of  x. 

!:x  =  (ALTER !- PERSIST ENT  X}  will  alter  the  value  of  x  to  be 
the  Batching  segaent  even  if  x  already  has  a  value. 

| x 1  *  (ALTEB {-TENTATIVE  jxj}  will  tentatively  alter  the 
value  of  |x|  to  be  the  matching  segaent  but  if  a  failure  backs  up  then 
the  old  vclue  of  |x]  will  be  restored. 

Gerry  Sussaan  and  I  have  developed  the  following  scheme  for 
looking  up  the  values  of  identifiers  in  interpreted  code.  On  the 


|  IDENTIFIER 


>4.1  G  '6  cl 


MECHANISM  OF  IDENTIFIER  LOOKUP 


|  PROCESS  |  STACK 


4. 1  page  64 


identifier  stack  vhen  an  identifier  is  bound  the  following  information 
is  stored: 

1.  the  name  of  the  identifier 

2.  the  current  value  of  the  identifier 

3.  the  place  on  the  stack  where  the  identifier  was  previously 

bound 

Associated  with  each  binding  environient  and  identifier  we  have  the 
place  on  the  identifier  i^ack  where  the  identifier  was  last  bound. 

4.1.2  Syntax  of  Expressions 

HATCHLESS  uses  Polish  prefix  notation  for  function  calls  with 
the  actual  call  delimited  by  <  and  >.  Of  course  we  use  the  characters 
(  and  )  to  deliait  lists.  Be  use  the  characters  [  and  ]  to  delinit 
vectors.  For  exanple  <♦  2  3>  evaluates  to  5.  If  y  has  the  value  4, 
then  <♦  .  y  1>  will  only  natch  5.  The  value  of  (.y)  is  (4)  and  the 
value  of  (<♦  . y  1>  (4  a)  .y)  is  (5  (4  a)  4).  If  the  function  call  is 
to  denote  a  segaent  then  it  is  deliaited  by  (  and  }.  The  function 
BEST  will  return  the  rest  of  the  list  that  it  is  given  as  an  argunent. 
For  exanple  <rest  (a  b  c)>  evaluates  to  (b  c)  .  But  (1  {rest  (a  b  c)  J 
e  f)  evaluates  to  (1  b  c  e  f).  Furtheraore,  {a  b  (rest  (1  (e  f)  q) ) 
k)  will  only  natch  (a  b  (e  f )  g  k) .  The  conponents  of  lists,  vectors, 
and  nodes  can  be  selected  by  subscripting.  For  exanple  <2  {a  b  c)> 
evaluates  to  b  and  <3  [  (a)  e  5)>  evaluates  to  5.  The  expression  <get 
|i|  | x| >  sill  return  the  location  of  the  |i|tk  coaponent  of  the 
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structure  ]x|.  Other  values  are  conputed  frci  patterns.  The  value  of 
[.y  (a  b)  .y]  is  £4  (a  b)  4].  Tuples  are  stored  in  the  stack  whereas 
the  vectors  are  garbage  collected.  lexically  the  scope  of  a  tuple  is 
the  smallest  enclosing  pair  of  <  and  >  or  {  and  }.  Otherwise  vectors 
and  tuples  are  indistinguishable.  An  arguaent  of  a  function  aay  be 
coaputed  in  parallel  with  the  ether  arguaents  by  deliaiting  the 
arguaent  with  |<  and  >  instead  of  <  and  >.  For  exaaple  7*3  could  be 
coaputed  in  parallel  with  2*4  in  the  expression  <♦  ]<♦  7  3>  <♦  2  4». 
An  arguaent  of  a  function  HCST  be  able  to  be  coaputed  in  parallel  if 
it  is  deliaitted  by  !j<  and  >.  In  other  words,  if  one  branch  becoaes 
blocked  the  otter  Bust  be  able  to  continue  execution. 
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4.2  Types 


The  type  hierarchy  is: 


<?>  for  the  universal  type. 

<WOHD>  for  priaitve  types  which  are  not  pointers. 

PALSE  for  the  logical  type  fajse.  All  other  data  are 
considered  to  be  true  in  conditional  expressions.  The  null 

function  call  <>  will  evaluate  to  IFALSE. 

CHABACTEB  for  a  character  such  as  !"a  or  !"U.  Again  we  are 
using  !  as  an  escape  character.  The  !  converts  *  into  the 

quote  for  a  single  character. 

<NUHBEH>  for  nunbers. 

<FIXED>  for  fixed  point  nuiber. 

FIX  for  a  siall  fixed  point  nuiber. 

BIG  for  a  big  fixed  point  nu»ber. 

FLOAT  for  floating  point  nuiber. 

<POiHTEB>  for  pointers. 

ATOH  for  atoas.  The  following  are  all  atois:  a,  too ,  and 
hello 

<STRUCTURE>  fox  structured  data.  The  operations  of  taking  the 
BEST  of  a  structure  and  selecting  the  nth  eleient  are  defined 

on  all  structures  including  tuples,  vectors,  lists,  and  nodes. 
For  soie  structures  the  operations  are  core  efficient  because 
of  special  hardware. 

TUPLE  for  a  tuple  of  elenents.  Tuples  are  allocated  fpoi 
the  stack  cf  a  process  and  are  deleted  on  procedure  exit. 
Tuples  occupy  contiguous  blocks  of  leacry.  Once  a  tuple 
has  been  created  its  structure  cannot  be  changed  and  its 
length  can  not  be  increased. 

VECTOR  for  a  vector.  Vectors  are  allocated  contiguous 
blocks  of  storage  which  are  garbage  collected  when  no 

longer  pointed  at.  Although  the  structure  of  a  vector 
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cannot  be  changed,  its  length  can  be  increased  at  the  cost 
of  a  garbage  collection.  Otherwise  vectors  are  identical 
to  tuples. 


ST8I8G  for  a  string. 
For  ezanple  "baw,  "3" 


This  is  just  a  vector  of  characters 
,  and  "a  b"  are  strings 


LIST  for  a  list.  Lists  have  the  advantage  over  vectors 
that  their  structure  can  he  changed  after  the]  have  been 
created.  They  have  the  disadvantage  that  it  takes  a  tine 
proportional  to  n  to  get  the  nth  eleaent. 

NODE  for  a  node  which  has  properties.  Nodes  are  the  aost 
general  fora  of  structured  data  in  the  language.  The 

others  are  included  for  reasons  of  efficiency  for 
specialized  structures.  The  coaponents  of  a  node  are 
obtained  oy  subscripting  which  is  currently  iaplenented  by 
hash  coding.  A  vector  is  approxiaately  one  third  the  size 
of  its  corresponding  representation  as  a  node. 


The  following  types  will  not  be  explained  here.  They  are 
included  only  fcr  coapleteness.  The  coaplicated  types  and  their 
abbreviations  are: 

JUNCTION  for  junction 
ACTIVATION  for  activation. 

STATE  for  state. 

ABC  for  a  node  arc. 

BIRD  for  bindings. 

<L0CATITE>  for  a  locative  or  generalized  location. 

VBCTOB— LOCATIVE  for  a  locative  to  an  eleaent  of  a  vector. 

TO FIE- LOCATIVE  for  a  locative  to  an  eleaent  of  a  tuple, 
tiliDlMG-LOCATIVE  for  a  loactive  to  the  value  of  aa  identifier 
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LIST-LOCATIVE  for  a  locative  to  an  eleaent  of  a  list. 
LIST-BEST-LOCATIVB  for  a  locative  to  the  rest  of  a  list. 
NODE -ICC ATI VE  for  a  locative  to  an  eleaent  of  a  node. 

LABEL  for  c  label  function. 

PBOCESS  for  process. 

STACK  for  a  stacX 
BING  for  a  ring 

ELEBENT-CAIL  for  a  eleaent  call. 

SEGMENT-CALL  for  a  segaent  call. 

SEGHENT-VALDE-CALL  for  a  segaent  value  call. 
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4.3  Simple  Examples  of  Hatching 


The  idea  of  structural  matching  is  fundamental  to  the 
MATCHLESS  processor.  By  means  of  the  primitive  function  CIS? 

| pattern!  j expression | >  we  can  determine  if  J pattern!  matches 
jexpressionj .  The  function  IS  has  the  value  true  if  the  match 
succeeds  and  <>  (which  is  FALSE)  otherwise.  Pattern  matching  takes 
place  through  the  use  of  side  effects  to  change  the  values  of 
identifiers  to  be  those  of  the  objects  which  they  match.  The 
assignment  statement  in  HATCHLESS  is  a  variant  of  the  primitive  IS. 
The  expression  <_  (pattern)  jexpressionj >  is  well  defined  only  if 
(pattern]  matches  (expression ] .  The  7alue  of  the  function  _  is  the 
value  of  J expression | .  Below  we  give  some  examples  of  matching  where 
the  values  of  identifiers  are  listed  after  assignment  statements  have 
been  executed.  He  use  the  character  -  to  delimit  segments.  For 
example  the  list  (a  b  c)  has  subsegments: 

— ,  -a-,  -a  b-#  -a  b  c~,  -b  c- ,  -b- ,  and  -c- . 

The  characters  <  and  >  are  used  to  delimit  function  calls. 

Cprog  [a  (t=atcm  h]  c] 

;"This  is  a  comment. 

He  are  inside  a  program  in  which  we  have 
declared  a,  declared  h  to  be  of  type  atom, 
and  declared  c" 

; " in  the  test  below 

the  function  IS  will  return  true 
since  tha  pattern  (_a  k  _h  !_c)  matches 
the  value  ({!)  k  b  o  a)M 
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<is?  (_a  k  _h  ! _ c }  {{3.)  k  b  o  a)>> 

a  gets  the  value  (1) 
h  gets  tie  value  b 

c  gets  the  value  (o  a) 

The  value  of  the  prograa  is  true  which  is  the  value  of  the  IS 
statement. 

<prog  [c  f  !=atca  hi  a] 

;*h  is  of  type  atoaH 

<is?  (i_c  _h  k  _a)  {a  j  b  k  q) » 

c  gets  the  value  {a  j) 

h  gets  the  value  b 

a  gets  the  value  g 

<prog  [first  last  middle  1 

<is?  (_first  !__alddle  _last)  {a  b  c  d) » 

first  gets  the  value  a 
aiddle- gets  the  value  (b  c) 
last  gets  the  ralue  d 

<prog  [a  b] 

<is?  (_a  _b)  <d) »  fails  because  there  is  only  one 

aleaent  in  (d) . 


<prog  [[l=atca  a]l 
’"a  is  of  t 


t  u  xs 
<is?  a 


_a  (o 


ype  atoa" 
t)»  fails 


because  (o  t'  is  ret  an  atoa. 


An  ex/res*ior.  that  consists  of  the  prefix  operator  followed  by  a 
identifier  will  only  aatch  an  object  equal  to  the  value  of  the 
identifier. 


<:rog  [a] 

<is?  (1_a  !.a)  {a  b  i  a  b  c)>> 
a  gets  the  value  (a  b  c) 

<proq  [a  b] 

<js?  x  !.a  ! b>  (a  b  x  d  x  a  b  x  d  g) » 

a  gets  the  value  (i  b) 

a  fail 're  occurs  because  (!.a  !_b)  will  not  ^atch  (d  x 

a  b  x  d  <?) 

a  gets  the  value  (a  b  x  d) 
b  gets  the  value  (q) 

An  expression  that  consists  or  the  prefix  operator  7  [the  value  given] 
followed  by  an  identifier  latches  the  value  of  the  identifier  if  it 
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has  one,  othervi.se  the  identifier  is  assigned  '  value. 


<prog  [a] 

<is?  ?a  t>> 
a  gets  the  valve  t 


a  is  declared  tc  be  of  type  fix  and  initialized 
on  entrance  to  the  prog.  Consequently  the  assignment  statement 


to  5 
fails. 


<prog  £  a  1 

vis?  ( !_a  !?a)  (a  h  c  c  t  a) >>  fails  because  once  a  is 
assigned  a  value,  a  can  only  match  a  segment  that  is  egual  to  the 
value  of  a. 

The  function  MATCH?  is  somewhat  tore  powerful  than  the 
function  IS?  because  it  can  match  patterns  against  patterns. 


to  3 


<prog  [x 


<match  ?x  ?y> 

{"link  x  and  y  by  matching  them  t°  each  other 
<match  ?x  3> 

;"let  x  have  the  value  3  and  tf>>ts  set  y  to  3” 


N 


•y 

;  "the  value  of  y  is  the  value  of  the  prog">  evaluates 


Restrictions  on  the  value  of  an  identifier  can  be  acguired  as 
the  result  of  a  match. 


<proq  [X] 

<match  ?x  <less  5>> 

;"x  will  only  natch  numbers  less  than  5" 

<match  6  ?z>>  fails  since  6  is  not  less  than  5 

Side  effects  can  pr.  , .agate  through  structures: 


<prog  [x  y  z] 

<match  ?x  [ ?y  !?z  ]> 

<match  {a  b  c)  ?x> 

;"y  gets  the  value  a  and  z  gets  the  value  (b  c) "> 
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4.4  Definitions  of  Procedures 


4.4.1  Functional  Procedures 


<FUKCTIC  K 

♦checker*  *activation-name*  [-function-declarations-] 
-expressions-)  where  ♦activation- nane*  and  ^checker*  are  optional, 
v  1  evaluate  to  a  function  which  will,  when  it  is  called,  bind  the 
foraal  parameters  in  the  | f unction-deciara ticnsj  to  the  actual 
parameters,  evaluate  the  -expressions-  returning  the  value  of  the  last 
one  as  the  value  ot  the  function.  The  ♦checker*  »ust  be  of  the  fora 
<|procedurei  -arguments-)  for  one  value  or  (J procedures  -arguaents-} 
for  multiple  values.  She  ♦checker*  is  treated  as  a  pattern  that  the 
values  returned  must  natch.  The  aatch  is  done  so  that  any  side 
effects  are  persistent.  The  j-f unction-declarations- J  is  of  one  of 
the  following  fores: 


jarguaents-speci f ication |  which  nay  be  one  of  the  following: 
[-foraal-paraneter-specif ications- ]  where  each  fornal- 

paraneter-speci ficat ion  is  of  one  cf  the  following  forms: 


|evaluaticn-<pecif  ication  |  where  each  Jeyal'.at  Ion- 
specification]  lust  be  one  of  the  following: 

*  J  identifier  I  lean  that  the  |  identifier  J  ^  to  be 
bound  to  the  write  rotected  DNEVALUhTID  corresponding 
actual  parameter. 

.identifier!  means  that  the  | identifier]  is  to  be 
bound  to  the  VALUE  of  the  corresponding  actual 

parameter 
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[  } attribute-specification f  1 evaluatioo-specif ication J  ] 
where  the  Jattribute-specif icatiunj  aust  be  one  of  the 
following: 

lattribute  j 
[-attributes- ] 

where  each  attribute  aust  be  one  of  the  following: 
-•"SPECIAL"  aeans  that  the  identifier  may  be  useu 

free  in  other  nodules.  The  symbol  -»"SPECIAl."  is  a 
uuigue  string. 

<1  procedure  1  -arguaents~>  means  that  the 
identifier  aust  always  be  either  unassigned  or 

bound  to  an  object  which  catches  the  pattern 
< | procedure  I  -arguments- >.  The  constraint  is 
enforced  by  PLAHHEE.  Any  side  effects  of  matching 
tLe  pattern  against  the  new  value  of  an  identifier 
are  persistent. 

r-fornal-paraaeter-specifi cat  ions-  -«"OPTIQSAL"  -optional- 
formal- parameter-specifications-  j 

where  an  Joptional-f ormal- parameter-specification i  is 
either  a  jf or mal- parameter-specification!  cr  [  Jat^ribute- 
specif icationj  [ leva luation-specif icationl  (initial- 
value|  V.  The  -<"CPTIONAL"  construct  is  due  to  Chris 
Heeve.  It  alows  for  optional  arguments  and  specifies  how 
the  identifier  is  to  be  initialize*  if  the  actual 
paramater  is  not  present. 

[-formal- parameter-specifications-  -•"BEST"  Jidentifier- 
specif Icationl ]  whicn  will  bind  the  identifier  in  lidentifxer- 

specif icationl  to  the  tuple  of  the  rest  of  the  arguments 
eval uatei. 

[-fomal-parameter-specif ications-  -»"8EST"  *  j  identifier- 
specification!  ]  whicn  will  bind  the  identifier  in  lidentlfiez- 
specif ication  1  to  the  write  protected  vector  of  tne  rest,  of 
the  unevaluated  arguments.  The  *  variant  is  due  to  Gar* 
Peshin. 


(-•"BUD"  (identifier-specification |  « argument s-specif cation  J  - 
declarative-]  is  used  to  first  bind  the  identifier  in 
Jident if ier-specif icationl  to  the  bindings  in  effect  vhen  the 
function  is  invoked.  In  alnost  all  cases  use  of  -•"BISD*  can 
be  avoideo  by  reading  the  function  into  a  local  syntactic 
block  so  that  no  identifier  conflicts  can  occur. 
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[-•"PfiTTEBH"  Jcalling- pattern!  | arguaents-specif cation |  ] 
defines  a  calling  pattern  for  pattern  directed  invocations. 

The  calling  pattern  is  of  the  for*  [-declarations-  |pattern|] 
which  declares  identifiers  for  | pattern;. 

For  example: 

«fauction  [-•"rest"  1]  <2  .x»  11  21  33>  evaluates  to  21 
since  <2  [  11  21  33  ]>  is  21 

«function  [^"rest"  *x]  .x> 
a 

<♦  3  4> 

c>  evaluates  to  [ a  <♦  3  4>  c ] 

«f unction  «x>  3>  evaluates  to  3 
«fanction  [xj  .x>  a>  evaluates  to  a 

«function  1=fix  [[!*fix  x]1  .x>  <♦  2  2»  evaluates  to  4  where 
!=£ix  is  <CF— TYPE  f ix> 

«function  !=fix  [[!=fix  x]]  <♦  .x  1»  2>  evaluates  to  3 

<'.function  l=fix  [[1-fix  x]  [I=fix  y]]  <♦  .x  ,j»  2  3> 

evaluates  to  5 

«f unction  [x  -•"optional”  [y  3]J  <♦  .x  .y»  4>  evaluates  to  7 

«function  £  x  -."optional"  [y  3]]  <♦  .x  -y>>  4  5>  evaluates  to 

«function  [[!*fix  *x]]  .x>  3>  *»»aluates  to  3 
«f unction  [*x]  .x>  a>  evaluate..  to  a 
« function  C  •  x 3  .x>  <♦  2  2>>  evaluates  to  <♦  2  2> 

8e  would  like  to  give  a  simple  exaaple  of  pattern  directed 
invocation.  Suppose  that  we  have  a  sink  s  which  we  need  unstopped. 
The  classical  solution  is  to  know  the  naae  of  a  plunber  which  could  be 
applied  to  the  sink.  Thus  for  exaaple  ve  aight  evaluate  <pluaber- 
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Peri nan  s>.  The  way  we  shall  actually  proceed  is  to  advertise  that  we 
need  a  sink  unstopped.  Of  ccuse  we  won't  let  just  anyone  work  on  our 
sink;  he  oust  cose  well  reccaaended.  For  example  he  should  be  cheap 
and  speedy.  Me  will  evaluate 


<call 


[ <[ unstop  s]  $5> 
<speedy> ]> 


to  offer  to  let  soae  ore  unstop  our  sink  for  $5  provinding  he  is 
speedy.  Sow  suppose  that  there  are  a  few  pluabers  around: 


<define  pluaber-Greenblatt 
<f unction 

[  -•"pattern" 

[[sink]  [unstop  ?sink]] 
fee  ] 

<cond 

[ <is  <less  $4>  . fee> 

<fail>  ]> 

;"if  the  fee  is  less  than  S4 
theu  fail" 

<Roto~Hooter  . sink> 

; "otherwise  apply  Boto-Rooter 
to  the  sink"» 


<define  pluafcer-Perlaan 
<f unction 

[  -•"pattern" 

[[sink]  [unstop  ?sink]] 
fee  ] 

<pour  Drano  .sink> 

;"pour  Drano  in  the  sink" 

<send~bill  <tiaes  2  *fee» 

;"send  a  bill  for  twice  the  originally 
agreed  fee"» 

To  try  to  get  our  sink  unstopped  we  eight  evaluate: 


<prog  [ ] 

<call 


[<[  unstop  s]  $5> 
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<speedy>  ]> 

;"advertise  for  a  speedy  plumber  to 
unstop  sink  s  for  $ 5 " 

<ccad 

[ <stopped-up?  s> 

<fail>  ]> 

;"if  the  sink  is  still  stopped  up 
then  try  again"> 

Suppose  that  both  plumber-Greenblath  and  pluaber-Perlaan  are 
dassifi''"  as  speedy.  Thus  PLANNEE  will  chose  one  or  the  other  to 
invoke  siuoe  both  have  patterns  which  aatch  the  calling  pattern 
[unstop  s].  If  either  one  fails  then  the  other  will  be  tried.  If  one 
returns  but  the  sink  is  still  unstopped  when  he  gets  back  then  the 
oess  the  first  created  will  be  undone  and  the  other  tried. 

He  can  define  the  function  reverse  which  returns  a  newly 
constructed  reverse  of  its  argument  as  follows: 


<define  reverse  <f unction  £x] 

<rule  [  ]  .  x 
! [ <enpty> 

.x] 

[ <structure> 

«storage  ,x>  {reverse  <rest  .  x>}  <1  .x»J 
-•"else" 

<error>>>> 

Thus  <reverse  [a  [b  c]  4]>  is  [4  [b  c}  a]. 

Functions  with  an  arbitrary  nuiber  of  argusents  are 
accoaaodated  by  passing  a  tuple  which  contains  the  evaluated 
arguments.  Suppose  that  we  already  have  a  function  PLUS  which  will 
add  two  nuabers  together. 


\ 
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<define  +  <£unction  pi 

;"let  tbe  nane  of  the  current  activation  be  pi" 

[-'"rest"  x] 

;"we  will  receive  a  variable  nunber  of 
argunents  in  the  tuple  i" 

<f  or 

[[result  0]  n] 

; "initialize  the  identifier  result  to  0" 

[[-•"test" 

<is?  [  ]  • x> 

<.pl  .result> 

;"exit  .pi  with  .result" 

;"each  tine  before  executing 
the  loop  test  to  see 
if  x  is  a  null  tuple  and  if  so  then 
return  the  result"] 

[-•"step"  <chop  x>] 

;"after  each  pass  through  the  loop  chop  x  by 
assigning  x  to  the  rest  of  x"  ] 

<_  rresult  <plus  <1  .x>  .result» 

;"the  body  of  the  loop  is  to  add  the  first  elenent  of 
x  into  the  result"»> 


<♦  3  [rest  (4  b  6))  7>  evaluates  to  21 
<♦324)  evaluates  to  9 


'ACTCB-FUNCTICK 

[JobjectJ  Jtailj  1 locativel  jchoicej  -function- 
declarations-]  -body->  is  exactly  like  the  function  FONCTIOH  except 
for  the  folowing: 

It  is  treated  as  an  actor  in  pattern  natching. 

The  first  argunent  Jobjectf  is  the  natching  object. 

The  second  argunent  (tail]  is  a  tail  of  the  natchinq  object  or  <> 
for  an  elenent  call. 
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The  third  argument  Jlocative)  is  a  locative  to  j object!  or  <>  if 
none  such  exists. 

Tb*  *ourth  arguaent  (choice)  is  not  false  only  if  the  actor- 
f  .ion  gets  its  choice  hew  auch  to  aatch. 

The  value  of  the  actor-function  is  the  rest  of  the  object  yet 
to  be  aatched.  Actor  functions  are  useful  as  in  internal  interface 
between  actors  and  functions. 

4.4.2  Macro  Procedures 

Macros  are  expanded  by  the  interpreter  and  by  the  coapiler. 

The  results  are  respectively  interpreted  and  coapiled.  Macro 
procedures  loo  A  like 
<MACBC 

]f crial-paraaeters)  -expressions->  The  expansion  of 
the  aacio  is  the  value  of  the  last  expression.  The  character  !*  is 
used  to  suppress  invocations.  For  exaaple  whereas  <+  2  2>  evaluates 
to  the  H'JHBEB  4,  !*<•♦■  2  2>  evaluates  to  the  function  call  <♦  2  2>. 

<define  choploc  <aacro  f’x] 

! *<putloc 

.x 

!'<rest  !*<in  ,x»»> 

The  aacro  choploc  will  take  a  location  as  its  arguaent  and  caase  the 

contents  of  that  location  to  be  changed  to  contain  the  rest  of  the 
previous  contents. 

<choploc  <at  y>>  expands  to  <putloc  <at  y>  <rest  <in  <at  y>>» 
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He  could  have  defined  the  function  ♦  as  a  aacro  as  follows: 


<define  ♦  <aacro  [-»”rest”  «x] 

;”let  x  be  the  vector  of  unevaloated  arguments” 

~ :ule  . x 

[ <eapty> 

;”if  x • is  <♦>  then  the  answer  is  0" 

0] 

ideclare 
[(.'first  rest] 

;”declare  identifiers  first  and  rest" 

[rfirst  !:rest] 

;”othervise  let  first  be  the  first  argument  and 
rest  be  the  rest  of  the  arguaents” 
!*<plcs  .first  !*<♦  !.rest» 

;”the  answer  is  written  nut  using 

binary  plus  instead  of  ♦  "]»> 


Thus 


<♦  3  2  4>  expands  to  <plus  3  <plus  2  <plus  4  0>» 


4.  4.  J  Actor  Procedures 


Actors  are  used  in  patterns  to  aatch  values.  The  priaary 
difference  between  functions  and  actors  is  that  functions  produce 
values  while  actors  aatch  then.  Actors  and  functions  take  their 
arguaents  in  an  exactly  analogous  fashion.  Examples  of  actors  are 
found  in  section  4.5  below. 

<ACTOB 

♦checker*  ♦activation-name*  | f unction-declarations]  - 
patterns->,  where  ♦activation- name*  and  ♦checker*  are  optional, 
evaluates  to  an  actor  which  when  it  is  invoked,  matches  an  object 
wuich  matches  all  of  the  -patterns-  after  the  identifiers  in  tbe 
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|f unction-declarations  1  are  bound.  The  |f unction-declarationsj  is 
interpreted  EXACTLY  as  in  FUNCTION. 

«actor  [“•"rest*  x]  <2  .x>>  1  a  3>  latches  only  a 
<<actor  [-»"restw  '  x]  <2  .x»  a  <♦  3  4>  c>  latches  only  <♦  3  4> 
«actor  [x]  .x>  3>  latches  only  3 

«actor  [x]  *x>  a>  latches  only  a 

«actor  !-fix  f[!=fix  x]1  .x>  <♦  2  2>>  latches  cnly  4  where 
!  =  fix  is  <OF-TIPE  f y. x>  . 

«actor  !*fix  [[!=fix  x]J  <♦  .x  1»  2>  natches  cnly  3 

«actor  !=fix  £[!=fix  x]  [!  =  £ix  y]]  <♦  .x  .y»  2  3>  latches 

only  5 

«actor  [[  !=fix  *x]J  .x>  3>  latches  only  3 

«actor  ['i ]  «x>  a>  latches  only  a 

«actor  [  ’  x  ]  .x>  <♦  2  2>>  latches  only  <+  2  2> 

4.4.4  Type  Procedures 

Type  procedures  are  used  to  define  new  types.  New  types  can 
be  defined  by  the  union*  direct  product,  and  direct  sm  of  already 
defined  types.  Types  can  also  be  defined  as  procedures  by  patterns. 

<define  eipty  <either  ()  [ ]>> 

Define  eipty  to  be  either  an  eipty  list  ()  or  an  eipty  vector 

t  h 
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<define  monadic  <either  <number>  !=atoa  <eapty»> 

Define  the  type  monudic  to  be  a  number  or  atomic  or  an  empty 
structure. 

<define  property-list  <actor  <list>  [  ] 

<star  (!=atoa  <?>)»> 

A  property  list  is  a  list  of  two  element  lists  whose  first  elements 

are  atomic.  The  actor  STAfi  is  the  K^*„ene  star  of  regular  expressions. 
For  example  the  following  are  property  lists:  (>,  ((a  (3))),  and  {(pi 
4)  (hello  (r  3))). 

4.4. 4.1  Onion  of  Types 

<EITHEE 

-alternative- types- >  is  a  type  which  must  be  one  of 
the  alternative  types.  For  example  we  can  define  the  type  <number>  to 
be  the  either  <fixed>  cr  the  type  of  float.  A  disjunction  of  types 
expresses  a  constraint  on  what  can  be  considered  to  be  of  the  new 
class. 


<define  number  <either  <fixed>  !=float» 


<prog  [[<nu*£er>  £x 


x  is  declared  to  be  of  type  <number>  and 
initialized  to  3" 


<cocd 

[<is?  !=*fix  .x> 
yes  ]» 

evaluates  to  yes  since  x  is  really  the  of  type  fix 
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4.8.4. 2  Product  of  Types 

<PfiODDCT 

|type-naae(  (kind)  ( fornal-paraneters(  -projection- 
specif icat ions- >  will  create  a  type  with  naae  (type-naiej  »ade  oat  of 
|kind|  storage  with  Jf craal- parameters |  as  for  functions  and  - 
projection-specifications-.  Each  1  pro jection-specif ication|  »ust  be 
of  the  following  fora: 

[ | apparent-pro jector-nanesl  [|initial|  jpatj  ]  ♦checker* 

1  actual- pro jector |  ]  The  (apparent-pro jectnrs-nawes (  is  either 
a  single  projector  naae  or  [(identifier!  [ list-of-pro jector- 
naaes|  ]  where  (identifier!  ranges  over  |  list- of-pro  jector- 
naaesj.  If  ♦checker^  is  present  then  only  objects  which 
■atch  ♦checker^  can  be  stored  in  the  component.  Rhen  an 
instance  is  constructed,  the  elements  are  given  the  value 
(initial).  Rhen  an  instance  is  decomposed,  the  pattern  (pat| 
is  used  in  Batching.  If  only  (initial!  is  given  then  |pat]  is 
assuaed  to  be  the  saae  as  (initial).  If  the  actual  projector 
is  not  specified  then  the  next  unused  integer  projector  will 
be  used,  in  actual  projector  which  is  a  procedure  call  gives 
rise  to  a  VIRTUAL  projector  storage  for  which  is  not 
necessarily  physically  present  in  the  data  structnre.  A 
product  type  can  be  RETRACTED  to  the  (kind)  of  storage  out  of 
which  it  was  constructed.  The  function  PBCDUCT  grew  out  of 
sowe  discussions  that  I  had  with  Vick  Pipplnger. 
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<define  coaplez 

<product  ccxplex  vector  [r  i] 

[real  [.r]  <nuater>] 

[iaayinary  [.i]  <nuaber>]>> 

The  type  coapler  {for  coaplez  nuaber)  is  the  direct  product  of  type 
<nuaber>  with  projector  real  and  type  <nuaber>  with  projector 
iaaginary.  The  object  coaplez  is  actually  two  procedures:  a 
function  which  is  the  constructor  and  an  actor  which  is  the 
decoaposer.  Constructor- decoaposers  iapleaent  the  overlap  of 
functions  and  actors. 


Ccoaplex  3  4>  evaluates  to  tcoaplex  [3  4]  where  #  is  the  type 

Barker 


<retract  <co*plex  3  4>>  is  [r  4]. 

<getc  real  <complex  3  4»  (whicn  coaputes  the  real  coaponent 
of  the  coaplez  nuaber  3>4i)  evaluates  to  3 


<getc  iaaginary  <c^>.;lex  3  4»  evaluate  to  4 


<prog  [f\nuaber>  a  b]] 

j^This  a  ccaaent.  We  are 

inside  a  prograa.  The  identifiers  a  ani  b  are 
declared  to  be  nuabets" 

;Min  tbe  assignaert  stateaent  below 

the  pattern  <coaplex  _a  _b>  aatchad 

again:.  che  expression  #coaplez  [3  4]" 

<_  Ccoaplex  _a  _b>  <ccaplex  3  4»> 
a  gees  the  value  3 
b  gets  the  value  4 


<getc 


real 

< 


<v-oaplex  <ceplace  7>  4> 
<ccaplez  3  4»>  evaluates  to  7 


We  need  to  be  able  to  get  at  tbe  locations  of  the  coaponents  of  a 
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product, 
purpose, 
the  value 


The  <getc  | projector 3  1  structured  is  used  for  this 
The  expression  CPOTLOC  1 1 J  J x | >  sets  the  location  |1|  to 
| x I  and  return  the  value  jx|. 


i 


<prog  ffx  <co«piex  3  4>]] 

;"x  is  initialised  to  Icoaplex  [3  4]" 

<putloc 

<getc  real  .x> 

2> 

j^x  no*  has  the  value  Icoaplex  [2  4 J**> 

Je  can  define  a  lover  triangular  aatrix  initialized  with  zeros 
as  follows: 


<define  triangular  <product  triangular  vector  [n] 

[i  <thru  1  .n>] 

t 

<ivectcr  .i  <f  unction  £  j]  0» 
;**each  coaponent  is  initialized  to 
a  zero  vector  of  length  iw  J 
<i vector  .i> 

;weach  coaponent  aust  be  a  vector 
of  length  i"J» 

<triangular  1>  evaluates  to  ftriangular  £[0]] 

<triangular  2>  evaluates  to  ftriangular  f  £  C  j  £0  0]J 

<2  <triangular  2»  evaluate  to  £0  0] 

He  can  define  the  «./pe  PDP-10  instruction  as  follovs: 


<define  instruction  <product  instruction  fix 

£op  acc  indir  index  addr  ] 

£  opcode  f.op]  !*fix  <bits  9  27>] 

[accuaulator  £.acc]  !=fix  <bits  4  23>] 

£  indirect  £. indir]  !=fix  <bits  1  22>] 

£  index  [.index]  !*fix  <bits  4  18>] 

[address  [.addr]  l=fix  <bits  18  0>]» 

A  POP- 10  instruction  has  9  bits  of  opcode  vhich  are  27  bits  froa  the 
right  end  of  the  word,  4  bits  for  accuauiator  nuaber,  1  bit  to 


% 


TV  Or 
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indicate  indirection/  4  bits  for  index  register  number,  and  18  bits 
for  an  address.  An  instruction  with  opcode  172  and  4  in  the 
accuaulator  field  causes  the  aachine  to  halt,  le  can  construct  such 
aD  instruction  with  instruction  172  4  0  0  0)  which  evaluates  to 
instruction  254400000000  in  octal. 

The  next  exaaple  illustrates  the  use  ~f  virtual  components. 


<define  aobjn-ptr 

<product  aobjn-ptr  fix 
[1  a] 

[length 

£.1] 

!=fix 

<signed-bits  18  18>] 

[address 

[.a] 

!=f  ix 

<bits  18  0>]» 


On  a  PDF- 10  an  aobjn  pointer  is  is  word  whose  left  half 
contains  the  negative  of  the  length  of  the  rest  of  a  vector  and  whose 
right  half  is  the  address  of  the  eleaent  of  the  vector  pointed  at. 

The  trailer  is  a  virtual  component  which  lies  jnst  after  the  vector. 


It  can  be  defined  as  follows: 


<define  trailer  <f unction  [x] 

<get 

<♦ 

<getc  address  .x> 

<-  <getc  length  .x» 

1> 

<getc  address  .  x»» 

<TIPE-¥BCTOH 

-element-specifications->  construct r  a  type-vector 


where  each  eleaent  specification  is  of  the  fora  [)type|  lvalue!]  which 
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initializes  the  apparent  coaponent  ) cypej  to  |value|. 


<getc  fix 

<type- vector 

[float  "above"] 

[fix  "below" ]»  evaluates  to  "below" 


<C  H A  B  ACT  £B—  V  EC IOB 

-eleaent-speci£ications->  construct  a  character- vector 
where  each  elewent-specif ication  is  of  the  fora  [ Jcharacterl  JvalueJ ] 
which  initializes  the  apparent  coaponent  Jcharacterl  to  lvalue). 


<putc 

<character- vector 

[I "a  beginning] 

[  !  "z  end  ]> 

[ i "a  very-beginning ]> 
evaluates  to 

•character-vector  [£!"a  very-beginning]  [!"z  end]] 


4.4. 4. 3  Extension  of  Types 

Be  need  to  be  able  to  extend  the  types  of  values  without 
otherwise  altering  then.  For  exaaple  3  oranges  are  net  the  saae  as 
the  fixed  point  nuaber  3. 

<EXTZISIOR 

Jtype-naaeJ  |aade-of|>  will  create  a  new  type  Jtype- 
naaej  which  is  an  extension  of  |aade-of].  Be  car.  define  the  type 
oranges  by 

<define  oranges  <extension  oranges  fix» 

Bow  <oranges  3>  evaluates  to  ioranges  3. 


<DBEXTEBD 


DIRECT  PRODUCT  CONSTRUCTION 


<COMPLEX> 


DIRECT  SUM  CONSTRUCTION 

<FRU  IT> 
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ltype-naae|>  returns  the  nane  of  the  type  of  vhich 
jtype-naaej  is  an  extension.  Thus  <unextend  oranges>  evaluates  to 
fix. 

Individual  eleients  cf  a  given  type  can  be  retracted  by  the 
function  BETH1CT. 

<retract  <oranges  3>>  evaluates  to  the  fixed  point  nunber  3 
Similarly  we  can  define  apples  by 

<define  apples  <extension  appl  fix» 

Then  ve  can  define  fruit  as  the  union  of  apples  and  oranges. 

<definc  fruit  <either  !=oranges  !=apples» 

<oranges  3>  evaluates  to  ioranges  3  which  is  a  <fruit> 

<♦  <oranges  3>  <apples  4»  is  an  error  because  you  can*t  add 
apples  and  oranges!  To  add  apples  and  oranges  the  function  ♦  Bust  be 
redefined  in  a  local  lexical  block. 

<is?  <fruit>  <oranges  3>>  is  true 

<is?  <fruit>  3>  is  <>  (which  is  FALSE) 

The  actor  <AS  (pattern)  J injector |>  will  be  defined  to  natch 
an  object  ]obj|  only  if  |obj)  is  of  the  type  of  the  range  of 

linjector]  and  JpatternJ  Batches  <BETBiCT  |obj|>. 

<prog  [!=fix  org] 

<is?  <as  :org  oranges>  <oranges  3»> 
org  gets  the  value  3 

<is?  <as  4  apples>  <oranges  4»  is  <>  (which  is  FALSE) 


4.4. 4. 4  Direct  Subs 
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The  direct  sua  of  types  can  be  constructed  as  the  disjunction 
of  the  extensions  of  the  types. 

4. 4. 4. 5  Hoaogeneous  Types 

<HCBOGEH  EOIJS 

|n]  istructcrej  ]type|>  will  define  |n|  to  be  a 
hoaogeneous  | structure]  of  |type|. 

<hoaogeneous  string  vector  character>  defines  the  type 
string  to  be  a  hoaogeneous  vector  of  characters. 

<hoaogeneous  big  vector  fix>  define  the  type  big  to  be 
a  hoaogeneous  vector  of  snail  fixed  point  nunbers. 

4.4.5  External  Interrrupts 

The  tvo  kinds  of  external  interrupts  that  are  recognized  are 
ATTE BTI05  and  ALABB  interrupts.  The  current  fora  of  external 
interrupts  is  due  Xo  Peter  Bishop.  The  attention  handler  is  governed 
by  the  global  value  of  the  identifier  HANDLER !-ATTEHTXGB  which  aust 
have  the  apparent  coaponents  -'"PROCESS"  and  -'"HANDLER".  If  the 
-'"PROCESS"  coaponent  is  <>  then  a  running  process  will  be  interrupted. 
The  initial  attention  handler  is 

!%<block  (<oblist  attention! ->  <oblist>)> 

<repcat  out 

[-•"labels" 

[-•"special" 

[  disaiss 

<function  [  ]  <.out» 


if 
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;"the  label  function  dismiss  vill 
dississ  the  interrupt"]]] 
<print  <eval  <rea-3»» 

!%<end-block> 

The  global  Talus  of  the  identifier  ALARBSI-TIHE  is  a  write- 
protected  list  of  alara  specifications.  Each  interrupt  specification 
has  the  following  apparent  components: 

-•"TIME"  is  the  tiae  after  which  the  interrupt  will  occur.  The 
interrupts  specifications  are  stored  in  order  cf  increasing  tiae. 

-•"IDENTIFICATION"  is  as  object  which  identifies  the  alara. 

-•"HANDLES"  is  evaluated  when  the  alara  goes  off. 

-•"PROCESS"  is  the  process  which  is  to  be  interrupted.  If  the 
coaponent  is  <>  then  a  running  process  is  interrupted. 

The  global  value  of  the  identifier  TIHEBSJ-BONTIBE  is  a  write- 
protected  list  cf  tiaer  specifications  for  all  the  PLANNER  processes. 
The  -»"TIHERS"  apparent  coaponent  of  each  process  is  a  siailar  write- 
protected  list  of  timers  for  the  for  the  runtiae  accumulated  bj  that 
process.  Each  interrupt  specification  has  the  following  apparent 
components: 

-»"TISE"  is  the  tiae  after  which  the  interrupt  sill  occur.  The 
interrupts  specifications  are  stored  in  order  of  increasing  tiae. 

-•"IDENTIFICATION"  is  an  object  which  identifies  the  alara. 

-•"HANDLEB"  is  evaluated  when  the  alara  goes  off. 

-•"PROCESS"  is  the  process  which  is  to  be  interrupted.  If  the 
coaponent  is  <>  then  a  running  process  is  interrupted. 

The  above  data  structures  can  be  modified  using  the  following 


2f 


uM  A  *•**«' 


r 
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functions: 

CSET-ALAH? 

Jidentif icat ion | 

2 tiie 1 
Jhandler | 

| process-to-be-interrupted |> 

will  set  an  alari  with  (identification]  which  will  go  off  after  ]tiae] 
interrupting  ] process-to-be~interrupted J  with  (handler],. 

CUMSET-ILAHfi 

(pattern*  for- identification! 

J  pattern-f or-tiie ( > 

unsets  all  alaris  whose  identification  latches  J pattern-for- 
identification j  and  whose  tiie  latches  J pattern-f or-tiie J . 

CSET-TIHEB 

(process] 

(identification ] 

jruntiiel 

(handler! 

| proceas-to-be-iaterr upted { > 

sets  a  tiser  for  |process|  with  (identification!  which  will  go  off 
after  (runtiiel  interrupting  ( process- to-be-interrupted J  with 
(handler].  If  (process]  is  <>  then  the  tiner  counts  the  tiie  need 
for  all  processes. 


COSSET -TIBEB 

(process] 

] pattern-for-identif icat ion | 

| pattern-f or-runtiie ] > 

unsets  all  the  tilers  for  (process]  whose  identification  latches 

| pattern-tor- identification]  and  whose  runtiae  latches  Jpatt«cn-for~ 

% 

runtiae] • 


•mm*  n 
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4.5  Functions  in  Expressions 


4.5.1  '  'Initio ns  of  functions 

Exasples  of  the  values  of  various  expressions  are  given  bexov: 

a  evaluates  to  a 

(a  b  c)  evaluates  i  a  b  c) 

<♦  1  2>  evaluates  to  j 

[3  (rest  (a  c)  ]  ]  evaluates  t  c) 

(a  b  <♦  2  3>)  evaluates  tc  (a  b  5) 

(a  b  {quote  (a  b)J)  evaluates  to  (aba  b) 

If  a  has  the  value  3,  then  (£  (.a)  ]  b)  evaluates  to  ([  (3)  ]  h) 

4.5. 1.1  Control  Functions 

4.5. 1.1.1  Conditional 

<OIPJLLSB 

)x)>  is  the  value  of  |x|  if  it  is  not  false  and  fails 

otherwise. 

<defin«  unfalse 

<f unction  [x] 

<coud 

[.*3 

[-"else"  <fail>  ]»> 
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<0B? 

-dis  juccts->  evaluates  each  of  the  disjuncts  in  turn 
until  one  of  thee  is  cot  false  in  which  case  it  is  returned  as  the 
value  of  the  function  08?.  Otherwise  the  value  of  the  function  oh?  is 
false. 


IX<blcck  (<oblist  or !->  <oblist>)  > 

<define  or?  <f unction  out  [-•"rest"  *a] 

Crepeat  [[’<>]] 

<cona 

[<eapty?  .a> 

<.out  .  v>]> 

< __  :v  <eval  <1  ,a>» 

<cond 

[•* 

<.out  ,v>]> 

<chop  a»» 

!*<end-block> 

<08 

-dis juccts->  is  exactly  like  OH?  except  that  if  none 
of  -disjuncts-  is  not  false  then  a  siaple  failure  is  generated. 


!S<block  (<oblist  or!->  <oblist>) > 

<define  or 

<f  unction  [-«"rest"  ®e  ] 

<uafalse  <or?  I.a>>» 

!X<end-block> 

<iID? 

-conjuncts->  evaluates  each  of  the  ccnjoacts  in  turn 
unless  one  of  then  is  false  in  which  case  it  returns  the  value  false. 
Otherwise  it  returns  the  value  of  the  last  conjunct. 
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!%<block  (Ccblist  and!->  <oblist>) > 

<define  and?  <f unction  out  [-’"rest"  •  a] 

<repeat  [[v  -'"true"]] 

<cond 

[<enpty?  .a> 

<.out  ,v>]> 

<_  : v  <eval  <1  .a>>> 

<cond 

[<not?  .v> 

<. out  <»]> 

<chop  a>»> 

!X<end-block> 

<AND 

-conjuncts->  is  exactly  like  AND?  except  that  if  one 
of  the  -conjuncts-  is  false  then  a  siaple  failure  is  generated. 


!%<block  (<oblist  and!->  <oblist>)> 

<define  and 

<fnnction  [-"rest"  *a] 

<unfalse  <and?  !.a»» 

!X<end-block> 

<*0T? 

|x|>  is  true  if  1 x |  is  false  and  otherwise  |x|. 


<define  not? 

<f unction  [x] 

<cond 

C  •  x  <>] 

[-"else"  -»"true*]»> 

OCT 

| x | >  is  true  if  ]x|  is  falsa  and  fails  otherwise. 


<define  sot 

<f unction  [x] 

<unfalse  <not?  ,x»» 
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<COND 

♦checker*  ♦activation-name*  -clauses->  is  the 
conditional  statement  of  the  language.  Each  clause  is  of  the  fora 
[predicate  -body-]  or  cf  the  fora  fDECLABE  [[-declarations-]  predicate 
-body-].  The  predicate  of  each  clause  is  evaluated  in  turn  until  one 
of  then  is  not  false.  Then  the  rest  of  the  eleaents  of  the  clause  are 
evaluated  in  turn  with  the  value  of  the  last  eleaent  being  the  value 
of  the  function  COND.  If  all  the  predicates  are  false  then  the  value 
of  the  function  CCND  is  false.  The  function  COND  is  due  to  John 
McCarthy. 

<cond  [<>  5]>  evaluates  to  <> 

<cond  [<>  5]  £-*"else"  6]>  evaluates  to  6 
If  the  operator  J  is  used  in  fron  of  a  clause  then  the  predicate  of 
the  clause  aay  be  evaluated  before  or  after  the  predicate  of  the  next 
clause  or  in  parallel  aith  it.  The  first  predicate  to  converge  to 
anything  other  than  false  wins  the  race.  There  are  obvious  tiling 
errors  in  the  indiscriminate  use  of  i  for  clauses 

<cond  |[3  a]  [4  b]>  evaluates  to  either  a  or  b 

<CATCH 

♦activation-name* 

[-declarations- ] 

Jx| 

[ ] k]  -"TUPIE"  | v |  ] 

-body-> 

establishes  a  catchpoint  and  then  atteapts  to  evaluate  |x|.  If  the 
evaluation  of  |x]  cones  back  with  an  abnormal  exit  then  the  catchpoint 
is  removed,  jk|  is  bound  to  the  type  of  exit  and  -body-  is  evaluated. 
If  control  runs  off  the  end  of  -body-  then  the  abnoraai  exit  is 
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restarted.  Ihe  abnormal  returns  which  are  currently  defined  are  of 
the  following  argument  tuples: 


-•"BESlCBE"  |activation|  -values-]  for  a  restoration  of  the 
ailpoint  |activation|  with  -values-. 


r -*"EXIT-CALL"  Jf  arguments J]  for  a  non  local  exit  call  of  JfJ. 
ihe  expressions  f  say  be  either  an  activation  or  a  junction. 


["•"EXIT"  lactivationj  lvalues!  ]  for  a  non  local  exit  t<_ 
lactivationj  with  -values-. 


-•"AGAIN?  lactivationj  ]  for  a  non  local  reiteration  of 
activation | . 


£->"TERHIHATE"  ]  for  a  termination  of  the  process 
for  exanple 


<prog  [  ] 

<prog  foo  [ ] 

<catch  £ ] 

C.foo  3  a> 

;"exit  .foo  with  3  and  a" 

[k  -»"rest"  v] 

<cond 

[<is?  .k  -»"exit"> 

<.bar 

<print 

(caught 

exiting 

with 

.  v) »  ]»> 

4> 

prints  (caught  exiting  with  £3  a])  and  then  evaluates  to  4 
<♦ 

<catch  [ ] 

4 

[k  -t*rest"  v] 

<cond 

£<is?  .k  -"fail"> 

<print  "you  can't  get  here!">]» 

<print  5> 

<fail» 

prints  5  id  then  fails  without  printing  anything  more. 
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<catch  [  ] 

<+  <print  4>  <fail» 

[k  “•"rest'1  v] 

<cond 

[<is?  .k  -*"f  ail"> 

<print  (caught  failure)  >}>> 

will  print  4,  print  (caught  failure) ,  and  then  continue  failing. 


<FAILPCINT 

♦checker* 

♦activation- naae* 

(-declarations-  ] 
jexprl 

[♦aessag*  +act ivation*  ] 

-body-> 

establishes  a  failpoint  and  then  evaluates  ]expr|.  If  the  evaluation 
does  not  produce  a  failure  then  the  value  of  the  function  FAILPOIHT  is 
the  value  of  |exprj.  If  the  evaluation  of  |expr|  or  sone  subsequent 
evaluation  ultinately  fails  back  to  the  failpoint  then  the  failpoint 
is  disestablished,  the  identifier  {nessage]  is  bound  to  the  failure 
nessage,  the  identifier  j activation)  is  bound  to  true  if  the  failure 
is  to  a  higher  level  activation,  and  -body-  is  evaluated. 


<failpcint  []  <fail>  £■  a] 

<print  hello>> 

prints  hello  and  then  restarts  failing 

<failpcint  [J  3  [i  a] 

<print  4?>  evaluates  to  3  but  if  a  failure 

ever  backtracks  to  here 
then  4  will  be  printed. 

<prog  foo 

<f ailpoint  [  ]  9  [■  a] 

<.foo  a> 

;"exit  .foo  with  a"> 

<fail>>  evaluates  to  a 


<BESTOBE 


I  activation]  -values->  will  restore  the  failpoint 


4.5  page  97 


naaed  by  jactivation|  and  exit  it  with  -values-.  It  is  an  error  if 

(activation)  is  not  the  activation  of  a  failpoint.  The  function 
BESTOBE  is  due  to  Drew  HcDeraott. 


<prog  way-out  [[a  3]] 

<print 

<failpcint  out  £  ]  .a  [a  a] 

<cond 

£<is  .a  5> 

<. way-cut  ,a>] 

[  -•"else" 

<restore  .out  .  a>]»> 

<inc!-persistent  a> 

<fail»  initializes  a  to  3,  prints  3, 
increaents  a  to  4,  fails  back  into  the  failpoint,  restores  the 
failpoint,  prints  4,  increaents  a  to  5,  fails  back  into  the  failpoint, 
and  finally  exits  .way-out  with  the  value  5.  The  following  function 
does  not  represent  good  prograaaing  practice  and  is  not  original,  but 
it  dees  illustrate  the  use  of  BESTOBE.  The  function  <CBANCBS 
(identifier]  (exceeded (>  will  decreneat  the  value  cf  (identifier)  each 
tiae  a  failure  propagates  through  it  until  the  value  of  (identifier) 
becoaes  less  than  or  egual  to  zero  at  which  point  (exceeded)  will  be 
evaluated. 


!X<block  (<oblist  chances !->  <oblist>)  > 

<define  chances 

<f unction  £*i  ^"optional"  [ »e  *<error>]] 
<failpoint  f  [  ]  <>  [^"optional"] 

<_  :.i  <-  ..i  1» 

<cond 

[<is  <less=:  0>  ..i> 

<eval  .e>] 

[  -»"else" 

<restore  .f  .  ,i>]»» 


!X<endblock> 


<B0LE 

♦checker*  ♦activation-naae*  [-declarations-]  |x|  - 
clauses-  — •"ELSE"-  -nct-fo«nd->  where  the  *activation-naae*  and 
♦checker*  are  optional  gives  a  rule  for  the  expression  |x).  Each 
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clause  is  of  the  fora  [Ipattern]  -body-]  or  of  the  fora  IDECLABE  [[- 
declarations-]  ipattern]  -body-].  The  value  of  |x]  is  watched  against 
the  pattern  of  each  clause  until  a  aatch  is  found.  If  there  is  only 
one  element  in  the  clause  then  the  value  of  the  function  BULB  is  <> 
which  is  false.  Otherwise  the  value  is  the  value  cf  the  last  element 
of  the  clause.  If  ncne  of  the  patterns  aatch  then  the  value  of  the 
function  BULB  is  the  value  of  -not-found-  if  it  exists  or  is  <>  (which 
is  FALSE).  If  a  clause  is  preceded  by  )  then  the  (pattern]  of  the 
clause  may  be  aatched  against  (x|  before  or  after  the  pattern  of  the 
next  clause  or  in  parallel  with  it.  If  aore  than  cne  | pattern] 
matches  then  the  first  one  to  natch  wins  the  race. 


<rule  [  j  3  £!=fix]>  evaluates  to  <>  which  is  false 
<rule  [x]  a  £_x  (.x  .x)  ]>  evaluates  to  (a  a) 

Crule  []  c  £d  e  ]>  evaluates  to  <> 

<rule  []  h  (1  a]  £h  b]  £3  c]>  evaluates  to  b 
<rule  [  ]  <-  3  1>  £1  b]  [<♦  1  1>  c]  -."else"  5> 

evaluates  to  c 

<rule  £]  a  [b  3]  “•"else"  7>  evaluates  to  7 
<rule  £  ]  a  £b  3]>  evaluates  to  <>  which  i  false 
<rule  £  ]  5  ]£<greater  3>  "big*]  £ <less  7>  "saall"  ]> 

could  evaluate  to  either  "big"  or  "ssall*. 


4.5. 1.1.2  Block 


<BECLAB1 

-declarations- >  declares  new  top  level  local 
identifiers  within  the  process  which  calls  DECLARE, 
of  the  identifiers  declared. 


It  returns  a  list 
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<ACTCS-CALLBB 

lobjecti 
Jtail | 

| locative | 

(choice | 

(pattern] 

(bindings-for-pattern| > 

enables  functions  to  call  the  pattern  aatcher  to  Batch  (pattern! 
against  objects  efficiently  in  special  cases. 

<C  ILL 

I junction-naae] 

£ < | f |  -send-args->  ] state-pa th-for-f|  (recoaaendation- 

for-f (  ] 

(9l> 

binds  the  identifier  ] junction-name)  to  the  junction  defined  by  CALL 
and  then  calls  ]f|  with  the  specified  argunents.  The  expression  (f| 
say  be  any  of  the  following: 


a  label  function  which  will  be  invoked, 
a  process  which  will  be  resuaed. 
a  function  which  will  be  invoked, 
a  port  in  which  -send-args-  will  be  queued, 
an  activation  which  will  be  exited, 
a  junction  which  will  be  invoked. 

a  pattern  which  will  atteapt  a  pattern  directed  invocation 
The  recoaaendation  Bust  be  of  one  of  the  following  foras: 

[-•"USE"  -pats-]  says  that  function  which  Batches  one  of  the 
patterns  -pats-  HOST  be  used. 
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[-»"THT"  -pats-]  sas  that  the  functions  which  Batch  the 
pattterns  -pats-  are  be  tried. 

[ ^"PILTEB"  |h|]  syas  that  the  functions 
<|h| 

<C AUDI  CATES  FUICTIOH  | £  1  Jstate-path-for-f | » 

are  all  to  be  invoked  (possibley  in  parallell. 

An  ordinary  function  call  < | f |  -args->  is  eguivalent  to 

<CALL 

<j£j  -args-> 

<POHCTIOB  [y]  ,y» 

where  y  is  arbitrary  identifier.  The  fora  of  the  argument  |g|  as  a 
function  is  due  tc  Jerry  Sussaan.  However*  if  |g|  is  of  the  fora 
[] function  I  {state-path  ]  then  it  allows  for  a  pattern  directed 
resumption  through  | state- pa th|.  Re  can  define  a  function  idivide  of 
n  and  d  which  returns  the  guotient  and  remainder  of  the  integer 
division  of  n  by  d. 


<define  idivide  <f unction  idivide  [n  d] 

<repeat 

C£r  .n]  [g  0]] 

<cond 

[<is?  <less  .n>  .r> 

<. idivide  .g  ,r> 

j^exit  .idivide  with  .g  and  .r"]> 
<_  ;r  <-  .n  .r» 

<inc  g»» 


Row  if  we  evaluate 

(a  {{idivide  7  3!}  b]  evaluates  to  [a  2  1  b] 

<call 

<idivide  7  3> 

<f unction  £a  b] 

<print  .a> 

<print  .b»>  prints  2  and  then  prints 


1 


h.5  page  101 


CCALL 

j junction-naaej 
< | f 1  -arguaents-> 

19 1 

Jstate-path j  > 

where  |£|  is  a  label  procedure  exits  tc  the  level  where  the  label 
function  |f|  is  defined  and  then  invokes  Jfj  with  the  specified  - 
arguaents-.  The  expression  <JfJ  -arguaents->  is  an  abbreviation  for 


<CALL 

<lf|  -arguaents- > 

<POHCTIOH  OUT  [-*"TUPLE«  I]  <.00T  *.X>» 

Label  procedures  and  junctions  are  generalizations  of  labels.  Label 
procedures  are  defined  using  the  -•"LABELS"  construct  in  block 
declarations.  See  the  exaaple  under  PfiOG.  The  function  jgf  is 
applied  to  the  values  received  if  the  process  vhich  calls  CALL  is 
resuaed.  Executing  <. \ junction- nave J  -send-args->  will  exit  to  the 
level  where  1 junction-naae j  was  defined  and  then  invoke  < 1 g |  -cend- 
args->.  If  the  optional  arguaent  jgj  is  not  present  and  |f|  is 
defined  in  another  process  then  the  process  vhich  calls  CALL  is 
terminated. 

<f EHPOEART 

1  junction- aaaej  <|f|  -arguaents>  |g|>  lakes  a  CALL  to 
| f 1  such  that  all  the  tentative  side  effects  within  the  scope  from  the 
point  of  the  call  to  the  exit  of  |fj  are  undone. 


<prog  [[x  0]] 

<teaporary 

«functioa  [  ] 

< _ x  *> 

; "tentatively  set  x  to  *"»> 
;"x  is  restored  to  9  because  the 
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call  vas  temporary” 

.  r>  evaluates  to  0 

<TEHPOBIZF 

(activation)  -values->  exits  (activation)  with  - 
values*  undoing  all  the  tentative  side  effects  within  the  scope  of 
| activation] . 


<prog  [[x  0]] 

<prog  out  [  ] 

< _ x  4> 

; "tentatively  set  x  to  4" 

<tenporize  . out> 

;"exit  the  activation  .oat  undoing  all 
the  tenative  actions  in 
the  scope  of  the  activation"> 
.x>  evaluates  to  0 


<prog 


[[*  0] 

-."labels" 

[f  <f unction  ( ]  .x>] 

{"define  t  to  be  a  label 
function  of  no 
argunents  that  returns  the 
value  of  x  ] 


< _ X  4> 

{"tentatively  set  x  to  4" 

<teaporize  .f> 

{"invoke  the  label  function  . f 

undoing  every  thing  which 
is  tentative  that  has  been  done  since 


vas  defined">  evaluates  to  0 


<prog  [£x  Oil 

<caXX  out 

< 

<f unction  [w] 

< _ X  .v> 

<tenporize  .out  *x» 
4> 

<f unction  [y] 

< print  .x> 

<print  .y»»  will  print  0 
and  then  print  4 
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<STSAlGHTBi 

<|f|  -argumtats»  makes  a  CALI  to  |f‘  such  that  a 
simple  failure  will  not  be  caught  within  the  scope  fro*  the  point  of 
the  call  to  the  ex  t  of  Jfi.  The  function  STBAIGBTBR  grew  out  of 
discussions  that  I  had  with  Jeff  Bill  and  Terry  Sinograd.  A  wery 
similar  concept  is  called  "fast  back"  in  parsing  grammars.  The 
expression  !s|form|  is  an  abbreviation  for  <STBAIGBTBI  Jform|>. 


<prog  ££a  3]  b] 

<_ 

<vel  a  b> 

4> 

<print  .a> 

<cond 

[<is?  .a  4> 

<f  mil>  ]> 

•b>  assigns  a  the  value  4,  prints  4,  fails 
back  inside  vel,  restores  a  to  have  the  value  3,  assigns  b  the  value 
4(  prints  3,  and  then  finally  evaluates  to  4. 

<prog  £[a  3]  b] 

Js<_ 

<vel  _a  b> 

4> 

<print  ,a> 

<cond 

£<is?  .a  4> 

<fail>  ]> 

•b>  assigns  a  the  value  4,  prints  4,  fails 
back  through  _  since  it  has  been  straightened  but  restores  a  to  have 
the  value  3  in  the  process,  and  thus  the  whole  prog  fails. 

<STBAIttflTEI-OP 

] activation | >  straightens  the  investigation  by  setting 
up  a  failpoint  which  will  convert  a  simple  failure  into  <7 AIL 
lactxvationl>. 
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<define  sfcraighten-up  <f unction  [activation] 
<failpoint  .activation 
[aessage  activa] 

<cond 

[<not?  <or?  .aessage  ,activa» 
<fail  <>  .activation>  ]>»> 


<PEBSX STENT 

I  junct  ion- oaae)  <|£)  -argu*ents>  |g|>  lakes  a  CALL  to 
1  £ |  such  that  all  changees  within  the  scope  froa  the  point  of  the  call 
to  the  exit  of  ]£|  ace  persistent.  That  is  they  will  not  go  avay 
autoaatically  by  backtracking.  The  expression  Ipjforai  is  an 
abbreviation  for  <PEBSISTEMT  ;fora|>. 


<prog  out  [[a  3]  b] 

<failpoint  [  ]  <>  [a  a] 

<cond 

[<is?  .a  3> 

<.ont  "win'*>] 

[-’•else** 

<print  [a  changed  to  .  a]> 

<„out  "lose,,>]» 

<_  <vel  _a  _b>  4> 

<print  ,a>  ~ 

<£ail»  initializes  a  to  3,  tentatively  alters 
a  to  4#  prints  4,  fails  back  inside  vel#  restores  a  to  3,  tentontavely 
alters  b  to  4,  print  3,  fails  back  to  the  faiJ point,  notes  that  a  is 
still  3  and  so  exits  the  activation  .out  with  *vxn”. 

<prog  cut  [ [a  3 J  b  ] 

<failpoxnt  [  ]  <>  [a  a] 

<cond 

[<is?  .a  3> 

<»out  *,t»in*>] 

[^"clse" 

<priot  [a  changed  to  .a]> 

<*oet  "los©'*>]» 

!p<^  <vel  _a  ^b>  4> 

<print  .a> 

<fail»  initialized  a  to  3,  alters  a  to  4, 
prists  4,  fails  back  into  the  failpoint,  notes  that  a  is  no  1 eager  4» 
and  ao  3exits  the  activation  .out  with  "lose0. 
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CIS? 

{pattern j  {expression!  Jis-tableJ  |is-apply-table|>  is 
true  only  if  J pattern |  Batches  the  value  of  J expression  1 .  The  Jis- 
tablej  nust  be  a  TYPE-VECTOR  and  so  nust  the  J is-apply- table | .  The 
function  IS  aafcains  twc  lccal  identifiers  TABLEi-IS  and  1PPLI-TA8LE!- 
IS  which  are  respectively  bound  to  jis-tablej  and  |is-apply-table| . 

CIS 

JpatternJ  Jexpressionl  Jis-tablel  |is-apply-table|>  is 
true  if  JpatternJ  natches  the  value  of  Jexpressionl  and  generates  a 
sinple  failure  otherwise. 
c_ 

Ipattern]  Jexpressionl >  is  an  assignnent  statement. 

The  value  of  the  function  _  is  the  value  of  Jexpression J . 


Cblock  (coblist  assign J->  Coblist>)> 


Cdef ine 


Tf unction  [’pattern  value] 

Ceval  ?*<is  .pattern 
,value>> 


4  -  value» 


Cendblcck> 

CHATCH? 

IpatternlJ  jpattern2J>  is  true  if  |pattern1{  Batches 
| pattern! |  and  is  false  otherwise. 

CH1TCH 

J pattern  1 J  }pattern2J>  is  true  if  jpatternlj  Batches 
Ipattern! |  and  generates  a  sinple  failure  otherwise. 


CEVAL 
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Jx|  |bj  fapply-tabiej >  evaluates  ]x|  using  the 
bindings  lb]  to  look  up  the  values  of  identifiers  and  fapply-table|  to 
apply  objects  according  to  their  types.  The  |apply~tablej  aust  be  a 
TTPE-YECTOI.  The  function  BY AL  naintains  local  identifiers  TABLE!- 
BT1L  and  APPLY  -TABLEI-&YAL  to  hold  the  current  jeval-tablel  and 
]apply-table|  respectively. 

<Q00T3 

t x I >  is  lx],  Re  nay  abbreviate  <QOOTE  |xl>  as  *|x|. 
For  exaaple  <prog  [[x  1]]  •<♦  .x  5»  evalutes  to  <♦  .x  5>.  lotice 
that  according  to  the  following  definition  QUOTE  write  protects  its 
arguaeni . 


<define  guote  <£ unction  [*x]  .x» 

<S OPPRESS 

I x | >  suppresses  evaluation  of  the  fora  |x].  Re  say 
abbreviate  <50PPPESS  | z | >  as  I'lsJ.  For  exaaple  <prog  [[x  1]]  !•<♦  .x 
5»  evaluates  to  <♦  1  5>. 


<PR0G 

♦checker  ♦  ♦activation-naae*  l deciaration- 
specification!  -body->  where  the  +activation-naae-v  and  ♦checker*  are 
optional  is  a  naaod  prograa  block.  The  |declaration-speci£icatioa|  is 
of  the  fore 


[ -or diaary~dec lacations- 
m^iabels*  -Inbel-declarationc 
-»*IBTER*ALSr/  -internal-declarations-  ] 
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where  LABELS  and  IHTEB1ALS  are  optional. 


Each  (internal-declaration)  is  of  the  following  form 

[jfi  <FilHCTICH  !  f  ornal-  paraneters  |  body->]  the  identifier  If  I 
xs  declared  to  fee  an  internal  function.  As  such  it  has 
special  access  to  the  local  identifiers  of  the  procedure  to 
which  it  is  internal.  The  identifier  ]f|  nay  not  have  its 
value  changed.  The  following  constructs  are  7ery  efficient 
within  the  procedure  which  delares  J  f |  to  be  internal; 

< I f |  -argunents-> 

[|fj  -arguments-} 

!  (I f  i  -argunents-!) 

Internal  functions  provide  a  rapid  leans  of  conaon 
subexpression  evaluation.  The  current  fori  of  internal 
functions  is  due  to  Feter  Bishop  and  Dave  Seed. 


Each  (ordinary-declaration |  is  of  the  following  fori: 

( lattribute-specif icationj  -bindings-]  causes  the  identifers 
in  the  bindings  to  he  rebound  with  the  appropriate  (attribute- 
specification  1 

where  each  binding  aust  be  one  of  the  following  twc  forns: 

(identifier!  indicating  that  the  identifier  is  rebound  and 
not  assigned  a  value 


[(identifier)  (value)]  which  rebinds  the  (identifier)  with 
an  initial  (value) 


where  (attribute-specification}  aust  be  one  of  the 
following: 

(attribute)  where  each  (attribute}  aust  be  one  of  the 
following: 

(pattern)  indicating  that  the  value  of  the 
identifier  aust  aatch  (pattern).  A  coaaoa  pattern 

is  <OF-IIPB  |type~saaej>  (abbreviated  !»)type- 
naae()  which  indicates  that  the  value  of  the 
identifier  aust  be  of  type  (type-nane). 


»v<V  *-W 
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-"SPECIAL"  indicating  that  each  of  the  identifiers 
is  special  aeaning  that  it  can  be  used  as  a  free 
identifier  in  other  procedures 

[-attributes-  ] 


Each  | label-declaration  1  is  of  the  fora 

[l£l  Jfunctionj]  so  that  execution  <JfJ  -arquaents->  wilj 
cause  ccntrcl  to  exit  to  the  point  where  ]f]  was  declared  and 

if unction  1  to  be  applied  to  the  evaluated  -arguments-. 

If  control  falls  through  the  bcttoa  of  the  function  PfiOG  then  it  tabes 

as  its  value  the  value  of  the  last  stateaent  of  the  body.  If  called 
as  a  procedure  a  label  exits  to  the  activation  in  which  the  label  was 
bound. 


<prog  foo  [[x  1] 

-"labels" 

[ nonfatal 

<£unction  [z] 

<print  (aon-fatal  .  x)> 
<.  ;x  a> 

<again  ,foo»] 

[fatal 

<f unction  [z] 

<print  (fatal  .z)> 
<.foo  lose> 

;"exit  .foo  with 
lose">3] 

;*ve  have  two  label  procedures 
nonfatal  and  fatal" 

<prog  bar  f[y  .x]  [x  1]] 

<cond 

[<is?  .y  1> 

<. nonfatal  first-ti»e>] 
[-"else" 

<. fatal  second-tise>  ]»> 

evaluates  as  fellows: 


foo  13  entered 
x  i3  initialized  to  1 

the  labels  fatal  and  nonfatal  are  bound 
bar  is  entered 
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y  is  initialized  to  1 
x  is  initialized  to  1 
<. nonfatal  first-tine>  is  invoked 
causing  us  to 
exit  EAB 

(ncn-fata.'  first- tine)  is  printed 
x  is  changed  to  a 

bar  is  entered 
y  is  initialized  to  a 
x  is  initialized  to  1 
<. fatal  second-time>  is  invoked 
causing  us  to  exit  FOO 
(fatal  second-tiae)  is  printed 
foo  is  exited  with  the  value  lose 


<BLOCK  BIND 

♦checker*  ♦activation-name*  [ -declarations- J 

OnBIN£"  1  block-bindings  l 

Irelative- bindings  I 
Jblock-naae| 

.  . , (block-declarations | 
jagainer |  ] 

-body-> 

is  exactly  like  PROG  except  that  before  the  -body-  is  executed  a  name 
jblock-na«e|  and  a  set  block  style  (e.g.  PROG,  FOR,  etc.)  bindings 
| block-declarations |  are  established  using  | relative-bindings |  to  look 
up  the  values  o£  any  free  identifiers.  The  resulting  binding 
environaent  is  bound  to  the  identifier  1  block-bindings | .  If  <AGAIN 
| block-naaej >  is  called,  then  Jagainer J  is  invoked.  The  function 
BLOCK BIND  is  useful  fox  writing  interpreters.  ie  could  define  REPEAT 
as  follows: 


<de£ine  repeat 
<functicn  p2 

[-•"bind"  bl  [’naae  *decs  --"rest"  *bd]] 

;"let  bl  be  the  bindings  before  p2  was  entered 
and  let  naae  be  the  naae  of  the  repeat, 
decs  be  its  declarations, 
and  bd  be  its  body" 
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<blockbind  pi  [[iter  «bd]] 

;"let  iter  be  the  rest  of  the  body 
to  be  evaluated" 

[-"bind"  b2 

•  bl 

.  nane 

•  decs 
<prog  [  ] 

<_  :iter  .bd> 

;"if  <again  . naae> 

is  executed, 
then  reinitialise 
iter" 

<again  »p1»] 

<ccnd 

[<enpty?  .iter> 

;"if  the  body  .iter  is  enpty" 

<_  :iter  .bc> 

;"set  iter  to  be  the  whole  body" 
<again  .p1>]> 

<eval  <1  . iter>  .b2> 

<chop  it.er> 

;"set  the  body  iter  to  the  rest  of  itself" 
<again  .  p1>»> 


<PR0CBIHD 

♦checker*  ♦activc.t jon-na»e+  [-declarations-] 

[— "BIHI"  ] procedure- bin dings | 

| rela  tive-bindings  J 
jprocedure-nane | 
j  procedure-dec larationsl  ] 

-body->  is  exactly  like  BL0CKB1HD  except  that  it  takes 
procedure  style  declarations  (e.g.  FOHCTIOM  and  ACtOB}  instead  of  PBOG 
style  declarations. 


4.5. 1.1.3  Escape 


<CALL 

J junction- nanej 
<| activation f  -values-> 

If  I 

{state-path] > 

leaves  the  activation  {activation]  with  the  given  values.  The 


expression  < {activation]  -values->  is  an  abbreviation  for 
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<CALL 

<|activation|  -values-> 

<FO*CTIOB  [X]  „X» 

where  X  is  an  arbitrary  identifier.  The  function  |f|  is  applied  to 
the  tallies  received  if  the  process  which  calls  Cl  LI  is  resuaed.  If 
the  optional  arguaent  |fj  is  not  present  and  +activation**naae*  is 
defined  in  another  process,  then  the  process  sbich  called  CALL  is 
terainated. 

<iGim 

] junction- nane)  |activation|  1ft >  reiterates  the 
] activation | If  (activation;  is  an  activation  in  another  process, 
then  the  process  which  calls  AGAIB  will  apply  the  function  |f|  to  the 
values  with  which  it  is  resuned.  If  the  optional  argunent  |f|  is  not 
present  and  lactivationl  is  defined  in  another  process,  then  the 
process  which  called  AGAIH  is  terainated.  It  is  illegal  to  execute 
<AGAIH  | activation | >  until  all  the  declarations  of  ] activation |  have 
been  processed. 

<prog  foo  [  ] 

<print  1> 

<again  . foo>>  prints  1  and  then  prints 

1, prints  1,  etc. 

<prog  bar  [Ta  <again  . bar>]  [b  3  1] 

<prxnt  (you  can't  get  here)»  causes  an  error 

<FAIL>  generates  a  siapie  failure  ia  the  watch. 

<?AIL  |aessagej>  causes  a  failure  with  a  )aessage|  to  be 
reported  above.  A  failure  with  a  wessage  can  be  caught  only  by  the 
function  FA:  .'CIST  which  is  explained  above. 


3/  .  'r- 


1 
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<FAIl 

1  message]  (place]  |f|>  generates  a  failure  to  |place| 
and  then  a  failure  with  a  | Message J  fro*  there,  the  (place]  »ay  be 
either  a  process  or  an  activation.  The  function  (f(  is  applied  to  any 
arguaents  received  by  being  resuaed  by  another  process.  For  exaaple 
down  inside  a  function  whose  activation  is  la|  and  which  has  been 
called  with  a  pattern  directed  invocation  executing  <fail  ^"caller*5 
] a | >  will  signal  that  none  of  the  other  alternative  functions  should 
be  tried. 

4.5.  1.1.4  Repetition 

.  •  •  •  •  •  •  •  •  * 

<REPEAT 

♦checker*  ♦activation-naae*  [-declarations-]  -body-> 
where  the  ♦activation-nane*  and  ^checker*  are  optional  executes  the 
nody  repeatedly  until  the  body  is  exited  by  calling  one  of  the 
functions  CAU.  or  AGAIN.  Iterative  prograaaing  in  ter*s  of  repeats 
has  the  advantage  that  all  loops  are  necessarily  nested.  The  repeat 
loop  *ay  be  exited  with  the  value  x  by  <.*activatioa-na*e*  x>  where 
♦activation-na»e*  is  the  nane  of  the  repeat  loop.  Executing  CAG1IN 
. *activation-naae*>  after  -declarations-  have  been  processed  transfers 
control  to  the  first  eleaent  of  -body- „ 

<FOR 

♦checker*  ♦activation-naie*  [-declarations-] 
[[-."IilTIAL**  -initial-action-] 

[-'"STEP*  -step-action-] 

[  -•■TIST*  J  predicate  |  -test-action-]] 
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-body-> 


where  the  *act ivation-raae+  and  ♦checker^  are  optional  is  defined  to 
be  an  abbreviation  for  the  following: 


<P80G  ♦checker*  ♦activation-naae*  [-declarations-] 
-intial-acticn- 
<BEPEAT  [  ] 

<CORO 

[ JpredicateJ 

-test-action- 
<« ♦activation-naae+  <>> 

;"exit  .*activation~naae*  with  <>"]> 

-body- 

-step-action-» 

The  FOB  loop  nay  be  exited  with  the  value  (x|  by  <.+activation-naae+ 
Jx|>  where  ♦activaticn-naae+  is  the  na»e  of  the  FOB  loop.  Executing 
<AGAIB  ♦actxvation-nane*>  juaps  to  the  point  labeled  AGIIH- in* the* 
expansion  above.  Alternatively,  we  have 


<FOB  ^checker*  ♦activation-naae*  [-declarations-] 

[[-•"IHITlAl"  -initial-action-] 

[''"TEST**  lpredicatej  -test-action-] 

[-.•J.IST*  |itenl  -»"IF"  |condition|  ] 

[  -»"STEP"  -step-action-  ]  ] 

-body-> 

where  the  ♦activation-naae^  and  ^checker*  are  optional  is  like  the  FOB 
loop  previously  described  except  that  the  value  of  the  for  statenent 
is  the  list  of  all  the  iteas  such  that  the  condition  is  true.  It  is 
equivalent  to  the  following  although  it  is  iaplenented  auch  aore 
efficiently  because  it  only  does  one  cons  for  each  itea  in  the  value. 
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<foe 

♦checker* 

♦active  ties- oa ■«♦ 

[ -declarations- 

[COLLECTED  {)]] 

;  "declare  COLLECTED  to  be  initialized  to  () " 

[  [  -."IIITIAL"  -initial-action-] 

[-."TEST" 

1  predicate | 

-tes t-action- 

<• ♦activation- naae*  .COLLECTED> 

;"ezit  .*activation-naae* 
with  .collected"] 

[-"STEP" 

<COID 

[ (condition | 

;"add  |itea|  onto  the  end  of 

COLLECTED  if  condition 
is  aet" 

< 

: COLLECTED 
((.COLLECTED 
]iten()  >  ]> 

.  -step- act  ion-]]  .  . . 

-body-> 


In  addition  to  being  able  to  list  the  elenents  produced  ve  can  append 
or  concatenate  then. 


<POB  ^checker*  ♦activation-nane*  [-declarations-] 

[[  (pattern)  | value!  -final-action- j ] 

-body-> 

where  the  ♦activation-naae*  and  ♦checker*  arc  optional  executes  the 
body  of  the  loop  once  for  c-cb  tiae  that  pattern  Batches  value,  <BEST 
value>,  <8BST  value  2>,  etc.  until  <BEST  value  n>  becoaes  eapty. 


<EOH 

♦checker*  ♦activation-nane* 
[-declarations-  [X  (value]]] 

([-•TEST" 

<IS?  <IHPTX>  .X> 

;"if  X  is  eapty  then  gait" 
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-f inal-actioES-  ] 

[^"STBP" 

;"set  X  to  the  rest  of  X* 
<CHOP  X>]] 

<CC«C 

[<IS?  Ipatternl  ,X> 

-body- 

;  "if  fpatternl  Batches  X 

execute  -body-'*  ]» 


<FOH  ♦checker^  ♦activation-nane*  [-declarations-] 

[[-»"IH"  1  pattern)  |7alue|  -final-action-]] 

-body-> 

where  the  *act ivation-naue*  and  ^checker*  are  optional  executes  the 
body  of  the  loop  once  for  each  tine  that  pattern  Batches  <1  | value |>, 
<1  <REST  |  value) »,  <1  <SEST  |  value]  2» ,  etc.  until  <RBS?  |  value |  n> 
becoaes  eapty.  The  -."IH"  variant  of  a  FOB  loop  was  invented  for  LISP 
II.  The  above  expression  is  equivalent  to: 


<FOH  vcheckerv  ♦activation-nane* 

[-declarations-  [X  lvalue!]] 

[[-."TEST" 

<IS?  <BBPTY>  ,X> 

;"if  X  is  eapty  then  quit" 
|f inal- actions | ] 

[  -»"STEP" 

;"set  X  to  the  rest  of  X" 
<CHOP  X>]] 

<CCSD 

[<IS?  ipatternl  <1  .X» 

-body- 

;"if  Ipatternl  Batches  the 
first  eleaent  of  X 
then  exncnte  -body-"]» 

For  exanple  we  can  define  a  function  which  returns  the  reverse  of  a 
list  as  follows: 


<define  reverse  <f unction  rev  [x] 

<for  [first  [answer  {)  ]] 

[(-"in"  : first  .x] 
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[-"final" 

<.rev  .answer> 

;Nezit  .rev  with  .answer"]] 

<_ 

: answer 

(.first  !. answer) »» 

Thus  <reverse  (a  b  c)>  is  (c  b  a)  The  following  function  returns  a 
list  of  the  fixed  point  nuabers  in  its  argunent: 


<define  nuabers  <f unction  [x] 

<for  [£!*fix  first]] 

[[-•"in"  :first  .x] 
[-"list"  .x]]»> 

Thus  <nuabers  (4  a  (3  4)  5.0  6  [3])  >  is  (4  6). 


<P0B  v-checker*  ♦activation-naae* 
[[-"IHC"  (j|  -"81"  | i|  - 
-bodj->  is  equivalent  to 


t  -declarations-  1 
UTIL"  | predicate |  ]] 


<FOH  ^checker*  vactivation-naae*  [-declarations-] 
[[-"TEST"  ) predicate |  ] 

[-"STEP"  <INC  Ij|  |i J  >  ]  ] 

-body-> 


<F0B  ^checker*  ♦activation-naae*  [-declarations-] 
[[-"IMC"  jj|  -"BY"  J i l  -"THBO"  JliaitJ]] 

-body->  is  equivalent  to 

<POB  ^checker*  ♦activation-naae* 

[-declarations- 

[S  <1BS  )i|>] 

[L  | Haiti  ]] 

;"S  is  the  absolute  value  of  the  step 

size  which  is  frozen  on  entrance 
to  the  FOB  loop" 

;"the  liait  1  is  also  frozen 

on  entrance  to  the  FOB  loop" 
[[-"I»C"  |j|  -"BY"  .S 
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-"UNTIL" 

<IS?  <GBBATEB  ,L>  Jjj>]] 

-body-> 


<FOB  ♦checker*  ♦activation-naae*  [-declarations-] 

[[-"DEC"  Jj|  -"BY"  lii  -"UNTIL"  | predicate |  ]  ] 

-body->  is  equivalent  to 

<FOB  ♦checker*  ♦activation-naae*  [-declarations-] 
[[-"TEST"  JpredicateJ] 

[-"STEP"  <DEC  Jji  1 i | > ] ] 

-body-> 


ld?>]3 


<FOB  ♦checker*  ♦activation-nane+  [-declarations-  ] 
[[-"DEC"  Ijl  -"BY"  1 i ]  -"THBU"  JliaitJ]] 
-body->  is  equivalent  to 


<FOB  *checker*  *activation-naae+ 

[ -  declare t ions- 

[S  <ABS  Ji|>] 

[L  jliaitj]] 

[[-"DEC"  Jj|  -"BY"  -S  -"UNTIL"  <IS?  <LESS  .  L> 
-body-> 


1]] 


<FOB  ♦checker*  ♦activation-naae*  [-declarations-] 

[[-"THBU"  ]liait 1  ] ] 

-body->  is  equivalent  to: 

<FOB  +checker*  ♦activation-naae*  [-declarations-  [I 

[[-"INC"  I  -"THBU"  <ABS  Jliait|>]] 

-body-> 


4.5. 1.1*5  Bulti-Process 
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Often  it  is  convenient  and  lore  efficent  to  have  aore  than  one 
HATCBLESS  process  in  existence  at  one  tiae.  By  a  process  ve  mean  a 
prograa  counter  together  with  a  stack.  Primitives  are  needed  for  the 
following  functions: 

1.  Creating  processes 

2.  Causing  then  to  run 

3.  Terainating  processes 

4.  Interrupting  processes 

5.  Single  stepping  processes 

<STEP 

| p J  In {  )condition|>  executes  the  process  Jp|  for  | n I 
elementary  steps,  unless  the  jeonditigo]  is  aet  in  .whticb.  case  it  ...  . 
returns  iaaediately.  The  value  of  the  function  STEP  is  the  nuaber  of 
eleaentary  steps  actually  executed  in  the  process  |p|.  The  existence 
of  the  function  STEP  means  that  FLASHES  functions  are  not  necessarily 
HOHOTONE  in  the  sense  of  lattice  theory.  A  function  f  aill  be  said  to 
be  COMTAIHED  in  a  function  g  if  whenever  <f  x>  converges  then  <g  x> 
converges  and  furthermore  <f  x>  =  <g  x>.  A  function  h  will  be  said  to 
be  HCIOTCHE  if  whenever  x  is  contained  in  y  then,  <f  x>  is  contained 
in  <f  y>. 

<I1VGKE 

| junction- aaae |  |p|  |n|  (condition)  I f  J >  executes  the 
process  ipi  through  )n|  complete  procedure  invocations  unless  the 
| condition)  is  net  in  which  case  the  valme  is  the  nuaber  of 


t 
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invocations  completed.  In  this  case  | condition!  is  a  function  which 
is  applied  to  the  values  returned  by  the  invocation.  After  the 
invocations  of  |p|  are  complete  control  returns  to  the  original 
process  where  jfj  is  applied  to  the  values  returned  by  the  last 
invocation  in  |p|. 

<PBOCESS 

| f J  j tcp-acti vationl  |scheduler|>  creates  a  new 
process  which  begins  execution  with  the  Jf|.  The  expression  <PBQCESS> 
returns  the  name  of  the  process  in  which  it  is  executed.  Processes 
enable  us  to  have  multiple  lcci  of  control.  We  can  hold  our  place  in 
the  problea  solving  process  in  scoe  of  the  processes  while  advancing 
others.  If  Jf]  is  a  function  then  the  process  expects  to  be  resumed 
with  arguments  for  Jf|  the  first  tine  that  it  is  entered.  If  |fl  is 
of  the  form  [|g|  Jportl]  then  it  will  hang  on  lportj  and  apply  the  the 
function  lg|  to  the  container  of  values  that  it  extracts  from  lportj. 
The  | top-activationj  specifies  how  nuch  of  an  existing  process  must  be 
copied  to  start  off  the  new  process.  Copying  a  process  enalbles  us  to 
preserve  its  current  state  and  still  allow  it.  to  continue  exectuon. 

The  process  is  scheduled  by  the  process  IschedulerJ.  The  value  of  the 
function  PB0CE3S  is  the  naae  of  the  created  process.  The  garbage 
collector  will  terminate  a  process  before  it  collects  the  storage  for 
the  process.  If  a  process  returns  or  fails  off  its  top  then  it  is 
terminated.  The  function  can  handle  normal  returns  and  failures 

as  it  pleases,  k  process  has  the  following  apparant  components: 
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-"STATUS"  is  the  status  of  the  process.  The  status  is  be  one 
of  the  following: 

•."BESUMEADLE"  -"STOPPED*1  -"ROM ABLE"  -"BONKING" 
-"TERMINATED" 


-"SCHEDULER"  is  the  scheduler  cf  the  process 

-"RUNTIME"  is  the  runtime  charged  to  the  crocess. 

-"TI8E8S"is  a  list  of  timers  fpr  the  process.  The  structure 
of  a  timer  is  explained  above  m  the  section  cn  interrupts. 


<CALL 

j  junction- naae| 

< I p I  ~send-args-> 
j  function! 
jstate-path| > 

resumes  execution  of  the  process  | p ]  with  the  arguments  -send-args- 
from  the  point  that  control  last  left  it  and  suspend  execution  of  the 

calling  process.  When  the  process  which  was  suspended  by  the  CALL 

•  •  >  •  •*  * 
statement  is  itself  later  resumed  then  the  arguments  received  are 

passed  as  parameters  to  {function).  If  the  optional  argument 

If unctionj  is  not  present  then  the  process  which  called  CALL  is 

terminated.  The  expression  <lpj  -send-args->  is  an  abbreviation  for 

CCALL 

<  J  p |  -send-args-> 

<F UNCTON  OUT  [-"TUPLE"  X]  <.OUT  !.X»>. 

FOi  example  «process  £oo>  2  a>  causes  <foo  2  a>  to  be  executed  in  a 
new  process. 

An  example  of  the  use  cf  more  than  one  process  is  in  computing 
the  fringe  of  an  expression.  The  fringe  of  an  expression  is  defined 
to  be  the  expression  with  all  interior  parentheses  removed.  For 
example  t.hs  fringe  of  (a  (b)  c)  is  (a  b  c)  and  the  fringe  of  ((a  (((b) 


4.5  page  121 


c) ) ))  is  (a  h  c)  .  Me  conjecture  that  the  problem  cannot  be  solved  in 

pure  LISP  without  the  use  of  the  primitives  CONS,  LABEL,  or  FUNCTION. 
Me  would  like  to  write  an  efficient  program  to  test  whether  two  s- 
expressions  have  the  same  fringe.  The  problem  is  analogous  to  testing 
whether  two  derivation  trees  for  a  context  free  grammar  •  ave  generated 
the  same  string.  The  function  fringe?  is  not  intrinsically 
interesting.  Its  importance  lies  in  that  fact  that  very  similar 
control  problems  arise  when  a  problem  solver  is  trying  to  extract 
information  from  two  different  areas  of  investigation  at  once.  He 
would  like  to  be  able  to  hold  our  place  in  one  of  the  investigation 
spaces  while  we  resume  computation  in  the  other,  flultiple  processes 
give  us  the  capability  which  we  need.  The  following  symmetric  form  of 
the  definition  of  fringe?  is  due  to  Bob  Frankston. 


<define  fringe? 

'function  cut  [x  y] 

<prog 

[  [  Fx 

<process  trec-walk> 

;"create  a  process  which  begins  execution 
with  the  function  tree-walk"  ] 

[ py  <process  tree-walk>]] 

<.px  .x  <process» 

<.py  .y  <process» 

<repeat  [temporary] 

<cond 

[<==?  <_  :temporary  <.px»  <.py» 
<cond 

[<is?  .temporary  ()  > 

<.out  -»"true">]>] 
[-»"else"  < « out  <»]»»> 


<define  tree-walk 

<f unction  [x  p] 

<.p> 

;"the  first  thing  to  do  is  to  resume 

the  main  process  with  no  arguments" 
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<tree-walk1  .x  ,p> 

;Hafter  doing  the  complete 

tree  walk  resume  the 
main  process  with  the 
special  value  ()" 

<•  F  0»> 

<define  tree-walkl 

<f unction  [x  p] 

<cond 

[<empty?  .x> 

;"if  the  structure  is 

empty  then  return 
and  try  to  find  another  atom”] 
[<is?  !=atom  .x> 

presume  the  main  process  with  the 
atom  we  have  found" 

<.p  .x>] 

[-."else" 

<tree-walk1  <1  .x» 

;"find  the  atoms  in  the 

first  element  of  .x" 
<tree-walk1  <rest  .x>> 

;"find  the  atoms  in  the  rest 
of  .x  and  then 

*  *  •  •  •  •  return  td  fin'ding  atoms  on 

the  remaining  branches”  ]>» 


<PCHT> 

creates  a  structure  which  contains  two  componteuts: 

EXPOHTSI-POBT  is  a  ring  which  holds  a  queue  of  containers  of 
exports  waiting  in  the  port. 

IH POSTERS! -PORI  is  a  ring  which  bolds  a  queue  of  processes 
waiting  to  take  containers  out  of  the  port. 

At  any  time  either  or  both  rings  may  be  empty.  Our  concept  of  a  port 
is  derived  from  Budy  Krutar,  Bob  Balzer,  and  innumerable  operating 
systems.  The  idea  is  that  the  port  acts  as  a  channel  through  which 
commerce  may  be  transacted  with  some  processes  exporting  through  it 
and  others  importing  what  the  others  export.  The  commerce  is 
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completely  containerized.  In  expression  <CiIl  <|port|  -values-»  will 

p^ace  -'values-  in  a  container  in  inort|.  Jhen  a  process  inports  f roi 
a  port  it  will  get  one  container  of  values  to  apply  to  a  function. 
Bspty  containers  are  allowed  in  which  case  the  function  of  the 
iaporter  will  be  passed  no  arguments. 

Another  exaaple  of  the  use  of  aultiple  processes  occurs  where 
there  are  t^ro  line  printers  and  a  nuaber  of  processes  which  would  like 
to  get  expressions  printed.  Suppose  that  <POBT-TO-pbIHTBBS>  is  the 
port  to  which  things  to  be  printed  are  exported.  Porter aore  let 
<PRIMT-CHAHHEL1>  and  <PBIHJ-CflAHHEL2>  be  the  channels  for  printer!  and 
printer2  restpectively. 


channel» 


<define  printer 

<f unction  [print-channel] 

<repeat  [ ] 

; "remove  the  next  eleaent 

from  the  print- port, 
print  it 

on  the  print  channel, 
and  repeat" 

<call 

U 

C 

<function  [x3 
<print 

.x 

.print- 

<por  t-  to-  printers>  ]»» 

<define  3etu£- printers  <f unction  [  ] 

«process  printer> 
j "create  a  process  for  driving 

the  first  printer  and  pass  it 
its  print  channel" 

<prin  t -channel  1» 

U> 

<call 
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«process  printer> 

<print-channel2» 

t  ]>» 

After  <setup-printers>  has  been  called,  then  <<port-to- 
printers>  |xj>  will  cause  Jx|  to  be  queued  and  printed  in  its  turn  by 
one  of  the  printers. 

Nov  ve  would  like  to  show  how  to  do  fringe?  nsing  ports 
instead  of  resuies. 


<define  fringe? 

<f unction  out  [x  y] 

<prog 

[[port-x  <port>] 

[port-y  <port>] 

[P* 

<process  [tree-walk  ,port-x]> 

; "create  a  process  which  begins  execution 
hanging  on  .port~x 
with  the  function  tree-walk"] 

;"at  this  point  an  activation  of  .px  is  waiting 
in  .port-x" 

[py  <process  [tree-walk  .port-y]>] 

;"at  this  point  an  activation  of  .py  is  waiting 
in  .port-y"] 

<call 

<• port-x  .x  ,port-x> 

; "export  . x  .port-x  to 

the  port  .port-x" 

[ .port-x  ] 

;"vait  for  a  container  of  values 
fron  .port-x*’> 

;"at  this  point-  an  activation  of  * 

.px  is  waiting 
in  .port-x" 

<call  <.port-y  .y  ,port.-y>  [.port-y]> 

;"at  this  point  an  activation 
of  .py  is  waiting 
in  .port-y" 

<repeat  [teaporacy] 

<cond 

[<=*? 

J  <_  :teaporary 
<call 


<.port-x> 
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arguments 
processes 
and  .  y" 


£  .port-x]» 
;"the  |  allows  the  ♦wo 

of  ==?  to  be  conputed  in  parallel  and  thus  allows  th« 

.px  and  . py  to  run  1b  parallel  to  find  the  next  atons  in  .x 


<call 


<. port-y> 

; "export 

an  eapty  container 
to  .port-y" 

[ . port-y  ] 

;"wait  for  a  container 
on  .port-y"» 


<cond 

[<is?  .teiporary  ()  > 
<.cut  -»"true">]>] 
[-."else"  < •  cut  <»]»»> 


<define  tree-walk 

<f unction  [x  p] 

<call 

<.p> 

; "export  an  e«pty  container  of  values 
to  the  port  .p" 

l- Pi 

;"wait  for  a  container  of  values 
on  the  port  p"> 

<tree-walk1  *x  .p> 

; "after  doing  the  coaplete  tree  walk 
export  (’  on  the  port  .p" 

<call 

<.p  ()> 

;  "insert  {)  in  the  port  .p" 

C.P] 

;"wait  for  a  container  of  values  in 
the  port  ,p">» 

<define  tree-walk  1 

<f unction  [x  p] 

<cond 

[<etpty?  .x> 

♦"if  the  structure  is 

enpty  then  return 
and  try  to  find  another  aton"] 
[<is?  !*atoa  „x> 

;"resuae  the  Bain  process  with  the 
atoa  we  have  found" 

<.p  .x> 

; "insert  . x  in  the  port  .p" 


<call 
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t«P] 

;ttwait  for  a  container 
of  values 
in  the  port  ,p">] 

f>"else« 

<tree-valk1  <1  .  x» 

;**find  tbe  atoas  in  the  first 
eleaent  of  ,x** 

<tcee-wlk1  <rest  .x» 

;"find  the  atoas  in  the  rest  of 
.x  and  then 

return  to  finding  atoas  on 
the  reaaining  branches'*  ]»> 


<BAIT-C1LL 

<t PI  -send-args->  Jfunctionp  is  exactly  like  CALL 
except  that  it  is  willing  to  wait  until  |p|  becoaes  resaleable. 

i<  8 P I  -args->  aight  create  a  new  process  in  which  to  evaluate 
< J  p J  -args->  in  parallel  with  the  noraal  order  ewalnation  of  the 
original  process*  The  first  t  in  the  previous  sentence  is  not 
aeta linguistic.  7or  exaaple  <*  ]<foo  3  4>  <bar  3  5>  |<+  ,x  7>  <g  2 
2»  initiates  evaluation  of  <f  oo  3  4>  and  possibly  in  para*  lei 
evaluates  <bar  3  5>.  If ter  <bar  3  5>  has  been  evaluated f  it  initiates 
evaluation  of  <♦  .x  7>  and  possibly  in  parallel  evaluates  <g  2  2>. 

When  all  of  the  values  have  been  conputed,  tbe  function  *  is  entered. 

! I < I p |  -args->  is  exactly  like  j<|pi  -args->  except  that  if 
one  branch  beco«*s  blocked  tne  other  is  guaranteed  to  be  able  to  try 
to  continue  execution. 


<prog  fco  [ ] 

<♦ 

1 1 <stop> 

<.foc  3> 

;*exit  .foo  with  3**»  evaluates  to  3 
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<FCBK 

<jp|  -args->>  resumes  execution  of  the  suspended 
process  Jp|  from  the  point  that  control  last  left  it  with  the 
arguments  -args-  and  in  parallel  continue  execution  of  the  calling 
process.  It  is  an  abbreviation  for 


<CAL1  <  1  p|  -args->  [  ]> 

For  exaaple  <fork  «prccess  foo>  <bar>  a»  causes  <foo  <bar>  a>  to  be 
executed  in  a  new  process  in  parallel  with  the  calling  process.  The 
value  of  the  function  FORK  is  |p|.  The  list  of  runnable  processes  is 
kept  in  the  global  value  of  the  identifier  RUNNABLE!— SCHEDULES.  The 
initial  scheduler  is  driven  by  the  following  handler  for  RUHTIHE 
interrupts  when  a  certain  amount  of  runtime  has  elapsed: 


MKblock  {<oblist  scheduler! ->  <oblist>)  > 

<function  [ ]  Cprog  twiddle 

[victem  [-«"g lobal"  runnable  deserving]] 

;"the  processes  that  are  still  deserving  to 
be  run  are  kept  in 
the  identifier  • deserving*” 

<lccker  [ ]  <getc  lock  schedule-gueue> 

;"lock  the  schedule  variables  while 
they  are  being  changed" 

Ccond 

[<empty?  .deserving* 

<__  : deserving  ,runnable> 
<again  ,twiddle>]> 

<_  {: victem  !: deserving)  ,deserving> 
<cond 

[<is? 

<getc  -»"status"  . victe*> 
-•"runnable  "> 

;"if  the  status  is 

runnable  then 
change  it  to  running" 


<putc 
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-*"running"  ]>  ] 


. victem 
[  ->"status" 

[  -«"else" 

<again  .  twiddle>]> 

;"this  scheduler  is  strictly  first  in 
first  out" 

<continue  . victea> 

<locker  [ ]  <getc  lock  schedule-gueue> 
<putc 

.victen 

[status  -»"runnable"  ]»»> 


!X<end-block> 

<TEBHI KATE 

-processes->  causes  -processes-  to  be  stopped,  their 
stacks  unwound,  their  titters  and  alaras  to  be  unset,  and  then  put  into 
a  state  such  that  they  cannot  later  be  resuned,  interrupted,  or 
continued.  A  process  is  automatically  terainated  when  it  returns  or 
fails  to  its  top  level. 

<STOP 

|pj>  stops  the  process  | p | ’  in  such  a  way  that  it  can 
later  be  continued  or  interrupted. 

<CONTI HUE 

1 p 1 >  causes  the  process  |pj  to  continue  execution  froa 
where  it  was  stopped. 

.  •  •  •  * 

<SUS?BND 

1  junction- naae J  |functionj>  suspends  execution  of  the 
process  which  calls  it.  It  is  an  abbreviation  for 

<CA1I  J junction- naae J  [  ]  Jfunction|>. 

If  the  process  is  later  resuaed  it  begins  execution  by  applying 
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JfunctionJ  to  the  arguments  received. 

<1 KTE88UPT 

j junction- name |  | p |  <|f|  -arguments->  jgj>  Hill 
interrupt  the  process  JpJ  to  evaluate  the  function  |fl  applied  to  - 
arguments-  IN  THE  PBOCESS  |pj.  If  ]f|  returns  normally  then  its 
values  are  given  as  arguments  to  Jg|.  Otherwise  |g|  will  be  applied 
to  the  arguments  with  which  it  is  resumed.  The  primitive  INTERRUPT 
allows  the  definition  cf  functions  which  are  not  HCNOTCBE  in  the  sense 
of  lattice  theory. 

4.5. 1.2  Data  Functions 

4.5.1.  2.1  Specialists 

4.5.  1.2.  1.1  Structure  Functions 

<STR  UCTUBE? 

1  x | >  is  true  only  if  Jx|  is  of  storage  type  vector, 

■  .  List,  stack,  ring,  or  node. 

<define  structure? 

<f unction  [x] 

<rule  [  ]  <storage  .x> 

[<cither 

vector 

list 

stack 

ring 

node> 
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-i"elseM 

<»» 


-»"true"  ] 


<E8PTY? 


jx |>  is  true  only  if  ]x|  is  an  empty  structure. 


<define  empty? 

<function  [x] 
<and? 


<structure?  ,x> 

<==?  Clength  .x>  0»» 


<R0NAD? 

] x l >  is  true  only  if  Jx|  is  not  decomposable.  In 
ether  words  ]xj  is  net  a  structure  or  it  is  empty. 

<define  monad? 

<f unction  [x] 

<or? 

<not?  <structure?  .x» 

<empty?  .x»>> 

<CL0SUHE 

Iprocedurej  |free-variafcles|>  returns  the  closure  of 
the  jprocedurei  with  the  free  variables  bound  to  their  values  at  the 
time  when  the  closure  is  constructed.  The  CLOSUBE  primitive  allows 
procedures  to  to  have  cwn  variables.  They  enable  os  to  easily 
construct  generators  such  as  those  of  GPS. 

The  function  twice  will  take  a  function  f  as  an  argument  and  return  a 
function  which  applies  f  to  its  argument  twice. 


<define  twice  <f unction  £f]_ 

<closure  <function  ^ x  ]  <.f  <•  f  .x»>  f»> 
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3 


«prcg  [x  3] 

«closure  <f unction  [  ]  .x>  x»»  evaluates  to 


<prog  [a  [b  1]] 

<  :  a  ^closure  Cfunctaon  [  ]  .b>  b» 

<~  :b  2> 

<.a>>  evaluates  to  1 

<prog  [x  4  J 
<prog  [ 

[y  <closure  <f unction  []  .x>  x>] 

[x  0]] 

<.y>»  evaluates  to  4 

Suppose  that  we  wanted  to  define  a  genecator  ]f|  to  be 
<eleaents  |x|>  such  that  each  time  that  <|f|>  is  evaluated  it  ceturns 
a  aew  eleaent  of  ]x|. 


<define  eleaents  <f unction  [x] 

Cclosure 

<f unction  [  ] 

<prog  [[next  <1  .x>]] 
<chop  x> 

.  next» 

x»> 


How  if  we  evaluate: 

<prog  [[f  Celeaents  (a  b  c)>]] 
<print  <.f» 

;*a  is  printed" 

<print  <.f» 

;"b  is  printed"> 

<IEST 


lx |  In |  enot-foandO  returns  the  resalt  of  taking  the 
rest  of  l x |  jnj  tines.  If  the  rest  of  ]x|  cannot  be  taken  |oj  tines 
then  enot-founde  is  evalnated. 


<rest  [a  4  d  f]  2>  evaluates  to  [d  f ] 

<1  <rest  <node  [1  a]  [2  b )>»  is  b 
<rest  <rest  [a  4  d  f]  2>  -1>  is  [4  d  f] 
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If  )n)  is  positive  then,  <rest  <rest  jxj  ]n|>  <-  |n|»  is  an  error  or 
is  identical  to  |x|.  the  function  BEST  vith  a  negative  jnj  nay  be 
applied  only  to  tuple  pointers,  vector  pointers,  and  node  pointers, 
it  nay  not  be  applied  to  list  pointers. 

<GET 

(indicator)  Jobject)  ♦not-foundO  returns  the  value 
under  | indicator!  for  the  ] object)  if  such  exists.  Otherwise  it 
returns  the  value  of  net-found.  Integer  indicators  have  special 
properties  so  that  structures  can  be  aade  out  of  list3,  vectors,  and 
codes  alaost  interchangeably.  The  expression  <| integer)  | object) 
♦not-foundO  is  an  abbreviation  for  <GET  (integer)  (object)  *00*- 
found*>. 


<3  (a  b  c) >  evaluates  to  c 

<-1  <rest  [a  bed]  3»  is  b 

<2  <rest  <node  £  f  00  1]  [3  a]  [2  b]>»  is  a 

<2  [a  (b  c)  d  ]>  evaluates  to  (b  c)  . 

<get  fco 

<node  [foo  1]  £4  a  ]»  evaluates  to  1 

<GET!-HO-acnitor 

lindicator)  Jobject|  +not- found* >*  is  exactly  like  get 
except  that  aocitors  for  the  location  under  (object)  with  arc  naae 
(.indicator)  will  not  be  triggered. 

CBAIT-6ET 

| indicator |  J object )>  is  like  GET  except  that  if 
>  1  object)  does  cot  yet  have  anything  under  J indicator!  then  the  process 

i 

I 
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is  suspended  until  | object]  bas  something  PUT  under  (indicator ! . 


<AT 

] x |  1 o I  *not-found*>  returns  the  location  of  the  value 
under  the  indicator  |i|  of  the  object  |o|. 

<putloc  <at  2  [a  4  ]>  8>  evaluates  to  [a  8] 

<AT  J o | >  is  the  locative  to  the  value  of  the  identifer  |o|  if 
]o)  is  an  atoa  and  a  locative  to  the  rest  of  | of  if  fo|  is  a  list. 

<AHC 


]o]  (indicator]  ♦not-found+>  is  the  arc  free  the 
object  ]o]  with  naae  J indicator!  if  there  is  one.  Otherwise  ♦not- 
founds  is  evaluated. 


<IIXTIAL 

|o|  *not-foundt>  is  the  initial  node  arc  for  the 
object  | o |  if  it  has  one.  Otherwise  it  returns  the  value  of  *not~ 
found*. 


<BEXT 

lx]  ♦nct-found*>  returns  the  next  arc  after  |s(  for 
the  object  |o|,  if  there  is  one.  Otherwise  it  returns  the  value  of 
♦not-f ound+. 

<EID?  ] o l >  is  true  only  if  |o|  is  an  end  node  with  no  leaves 
leaving  it. 

<LASf? 

|x)>  is  true  only  if  |x|  is  the  last  arc  of  the  node. 

<1 VDICATOB 

| x | >  is  the  indicator  for  the  arc  (x|. 
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<indicator  Cinitial  Cnode  [a  3]  [4  "r"  ]»>  is  a 

<HEAD 

|xl>  is  the  object  at  the  head  of  the  arc  |xj. 

<head  <arc  <put  3  [larger  2]  ’  smaller  4]>  smaller»  is 
3 

<TAII 

|xl>  is  the  object  at  the  tail  of  the  arc  Jx|. 

Ctail  <arc  <node  [a  3]  [4  »r"  ]>  a>>  is  3 
<LOCAHVE 

1 x | >  is  the  location  which  holds  the  object  at  the  end 

of  the  arc  | x J . 

<COPT 

lx|>  will  coapletely  copy  |x|. 

<==? 

|xj  J y  1  >  is  true  only  if  |x|  and  | y |  are  identically 

the  sane  object. 


<=? 


1  x I  |yl>  is  true  only  if  \x\  and  j y j  print  the  saae  as 


structures. 


<define  =?  <f unction  egual  [x  y] 

<egual1  .x  .y  .egual»> 

<define  egual  1  <f unction  eguall  [x  y  equal  1 
<cond 

[<or?  <aonadic?  ,x>  <eonadic?  .y» 
<cond 

[<==?  .x  ,y> 

-»"tr  uew  ] 
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(-."else" 

<. equal  <»]>  ] 

[<=^=?  <type  ,x>  <type  .y>> 

<repeat  [ ] 

<cond 

[<eapty?  .x> 

<cond 

[<e«pty?  .y> 

<.equal1  -."true">] 
[-."else" 

<. equal  <»]>] 

[<eapty?  .y> 

<. equal  <»]> 

<prog  out  [ ] 

<e quail 

<1 


•  x 

<cond 

[ <has?  1  .y> 

<. equal  <»  ] 
[  -."else" 

<.out>  ]» 


<chop  x> 
<chop  y>>] 

[  -."else" 

<.  equal  <»]»> 


i*,.qual» 


<. equal  <»> 


<SIHXLAB? 


I x ]  | y l >  is  true  only  if  |x{  and  ]y|  have  siailar 
values  under  their  respective  positive  indicators.  For  exaaple  (3 
"a 4"  [  !"a  ])  is  siailar  to  [3  (!"a  !"4)  "a"]. 


<define  siailar?  <f unction  sia  [x  y] 
<sialar1  .x  .y  .sia>» 


<define  sinilarl  <f unction  sial  [x  y  sia] 
<cond 

[<or?  <aonadic?  .x>  <aonadic?  ,j» 
<ccnd 

[<*?  .x  .y> 

-•"tme"  ] 

[-."else" 
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<.  sia  <»]>] 

[-."else" 

<repeat  [ 3 

<ccnd 

[<eapty?  ,x> 

<cond 

[<eapty?  .y> 

C.sial  -."true">] 
[-."else" 

<.sia  <»]>] 

[<eapty?  .y> 

<.sia  <»]> 

<pcog  out  [ J 

<siailar1 

<1 


<1 


.x 

<cond 

[ <has?  1  .y> 
<.sia  <»J 
[-."else" 

<.out>  J» 


•y 

<.sia  <»> 

,sia» 

<chop  x> 

<chop  p>]»> 


<ISOHOBPHIC? 

| x |  J y | >  is  true  only  if  ]x!  and  |y|  ace  isoaorphic  as 

graphs. 

f 

<define  isoaorphic?  <f unction  iso  [x  j] 

<iso1  .x  5y  .iso»> 

<define  isol  <functicn  [x  y  iso] 

<cond  .  « -  • 

[<**?  <type  .x>  <type  .y» 

<prog  out  [ ] 

<snb-iso1 

<initial 

.x 

<.out> 

;"if  .x  has  no  arcs  then  exit 
.oot"> 

•  I 

,iso» 
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<prog  out  [ J 
<sub-iso1 

<initial 

•y 

<. out>> 

. X 

. iso>> 

vtrue"  ] 

[  i^else** 

<.is»1  <»]»> 


<tiefine  sub-iso  1  <functiou  sub-iso-n  [x-arc  y  isc] 

<repeat  [  ] 

<iso  1 

<tail  .x-arc> 

<get  <iadicator  .x-arc> 

.  y 

<.iso  <>> 

;"f  .y  uoes  not  have  a  arc  with 
<indicator  ,x-arc>  then, 
exit  .iso  with  <>**> 

.iso> 


.x-arc 

<next 


.x-arc 

<. sub-iso- n> 

;"exit  .sub-iso-n  if  there  are  no 
■ore  x-arcsM»»> 


<PUT I-PE HSISTEMT 

lobiectj  -  proper ties->  puts  the  properties  on  the 
jobject] .  A  property  of  the  fora  [Jindicafccr]  jv]]  puts  the  value 
) v |  under  the  jindicatoc|.  A  property  of  the  fora  £ i indrcator i ] 
deletes  the  | indicator]  froa  the  object.  Integer  indicators  have 
special  properties  so  that  structures  caa  be  Bade  oat  of  lists* 
vectors*  and  nodes  alao3t  interchangeably. 

<put  <node  [a  a]  [3.5  c  ]>  [a  b]  [3.5]  [[e]  9]> 
evaluates  to  inode  [[a  b]  [[e]  9]] 

<put  (a4)  £1  «c«]>  evaluates  to  <®c"  h) 
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Properties  can  be  put  on  ANI  of  the  data  types  of  BATCHIESS.  For 
example  <pat  3  [size  s»all]>  puts  the  value  stall  under  the  indicator 
size  for  the  fixed  point  nuaber  3.  The  ability  to  associate  any  piece 
of  data  with  any  othet  piece  is  very  useful.  For  exaaple  Gerry 
Sussaan  has  pointed  out  that  conaents  can  be  iapleaented  in  this  way. 
The  degree  to  which  an  expression  has  been  siaplified  can  be  recorded. 
For  exaaple  we  ai^at  <put  ' <♦  3  4>  [siaplified  canonically  ]>  to 
indicate  that  *<♦  3  4>  has  been  siaplified  canonically. 

<PUT!- TENTATIVE 

lobjectj  -properties->  is  exactly  like  PUT  except  that 
the  properties  of  Jobject]  are  restored  on  backtracking. 

<PUT1-N0— BONITOH 

lobjectj  -properfcies->  is  exactly  like  PUTI-PBFSITENT 
except  that  the  monitors  for  the  locations  are  not  triggered. 
<POTBEST!-PEE SI STENT 

Jx«  Jy|  | n ]  ♦nat-found+>  changes  the  BEST  of  the  list 
<rest  JxJ  | n 1 >  to  be  Jy|  where  JyJ  must  be  a  list.  If  Crest  Jx|  <♦ 
jn  I  1>>  is  not  a  list  then  «-nct-foundv  is  evaluated. 

Cputrest  (3  a)  (4  5)  >  evaluates  to  (3  4  5) 

CPOXEE  ST  '.-TENTATIVE 

III  lyl  |nj  4-nct-foundO  is  exactly  like  POTBEST 
except  that  JxJ  is  restored  on  backtracking. 

Cdefine  putrest! -tentative  Cfuncticn 
[x  -•"optional" 

[y  0  3 
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[n  0] 

[net-found  !,<error>]] 
<failpoint  [[save  <rest  .x  ,n>]] 

<putrest  , x  .y  .n  .not-found> 

[ -"optional" J 

<putrest  .x  .save  ,n>>» 


<C HOP! -PERSISTENT 

jx|  | n I  < not-f ound+>  assigns  the  identifit?  Jx|  the 
rest  taken  |n|  times  of  its  current  value.  The  function  CHOP  was 
invented  for  a  variant  of  LISP  at  MITHB. 


!X<block  (<oblist  chop!~>  <oblist>)> 
<define  chop 

<f unction 
[  ‘x 

-"optional" 

[n  1] 

[*not-fcund  '<error>]] 

<_ 

: .  x 
<rest 


! *<end-block> 


. .  x 
.  n 

•  nct-f  ound»>> 


<prog 


uv  (i  2)  11 
<chop  v>> 


evaluates 


to  (2) 


<C HOP! -TENTATIVE 


Jx|  1 33 1  +not-found+>  is  li I  .?  CHOP  except  that  its 
results  are  not  undone  on  backtracking. 


!%<block  {<oblist  chcp!->  <cblist>)> 

<aetine  chop 

<f unction 

C  'x 

-"optional" 

[n  1] 

[ *  not-f cund  *<error>33 

< _ •  *  <rest  ..x  .n  .not-found»» 


!X<end-biock> 
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<LBSGTH 


Jx|>  returns  the  length  of  the  value  of  |x|. 


<length  (a  b  c)>  evaluates  to  3 


<define  length  <f unction  In  [x] 

<f or  [[n  0]j  J 

[[-•"in*  <?>  .x] 

[-•"final"  <.ln  .n> 

;"exit  .Jn  with  .»*•] 
<inc  n>]»> 


<IHD2X 

) x | >  returns  the  rest  index  of  |xj.  The  function 
INDEX  is  only  defined  for  vectors  and  nodes. 

<index  <rest  <rest  [ae!"ee£g]2>  3»  is  5 


<TCP 


*not-f  oundO 


ixj  |n?  ♦not-found*>  is  <BEST  lx|  <-  }n !  <INDBX  I x | » 


<BOTTOH 

j x f  J n |  vnot-foundO  is  <EEST  |x|  <-  <IENGT8  |x|>  | a | > 


♦not- found  *> 


OJNIQUIZE 

|value|>  returns  a  pointer  to  the  unique  copy  of 
(value | .  The  function  0HIQ0IZB  can  be  used  to  save  space  and  tixe  in 
coaputations.  The  expression  <0NIQDIZE  1  value! >  aay  be  abbreviated  as 
!-*(valoeJ.  the  function  0HIQ0I2E  is  due  to  Peter  Bishop. 
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<uniquize  "efg1^  is  -*"e£g" 

<uniguize  (a  l"b  £"e"  3])>  is  -»{a  !"b  3]) 

<prog  ££xja  b  c3  3  3 

<uniguize  .x> 

<uniguize  <copy  ,x>»>  is  true. 

<UHIQUEt*? 

1*  l>  is  true  only  if  | x }  is  a  uniquely  created  ccpy  of 
1  x]  i.e.  to  be  <=?  Jxj  <08IQ0IZ2  |xj». 

<IMCBEASIHG? 

-elements- >  is  true  only  if  -elements-  are  arranged  in 
increasing  order  in  the  the  total  ordering  on  unique  expressions. 
<SUBST1T0TE 

Jx|  (patters!  Jz|>  substitute  the  value  of  |x|  for  all 
expressions  in  ]z|  that  natch  ) pattern). 

Substitute  a  !=ato»  (1  (x  z) )  >  evaluates  to  (a  (a  a)) 


MKblock  (<oblist  substitute  !->  <oblist>)  > 

<define  substitute  <£unction 

£  *  *P  *3 

<subst 

.  X 

<eral  !'<actor  £]  .p>> 

.  z»> 


<define  subst  <f unction  [i  p 
<rale  £  J  .z 

£<-P> 

•  *3 

[<sonadic> 

•*  3 

[<linear  (1}> 

<<type  .z> 

<subst  .x  .p  <1  .*» 

(subst  .1  .p  <rest  .  z>}>] 
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[  <?> 

.2  ]>>> 

!%<end-block> 

<HEKBEB? 

|pat|  jstruc|>  is  the  tail  of  Jstrucj  whose  first 
eleaent  matches  lpat|  if  there  is  one  and  otherwise  is  <>. 


c] 


Cmeaber?  !=aton  [3  4.5  (a)  b  6  c]>  evaluates  to  [b  6 


!X<blcck  (<oblist  member?>  <cblist>)> 

<define  member? 

<f unction  [  ’  p  s ] 

<metnber  1 

<eval  !*<actor  [J  ,p» 
.s»> 

<define  meaberl 

<function  out  [p  s] 

<repeat  [  ] 

<cond 

[<is  <empty>  .s> 
<.out  <»] 

[ <is  <.p>  <1  . s>> 
<.out  .s> ]> 
<chop  s»» 


!  *<endbiock> 


4.5.  1.2. 1.  1. 1  list 


<1IST! -CONSTRUCTOR 

-values->  constructs  a  list  of  -values-.  It  is 


eguivalent  to  (-values-) 
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4.5. 1. 2. 1. 1. 2  Vector 

Any  expression  enclosed  within  •• {"  and  ») "  evaluates  to  a 
list.  Any  expression  enclosed  within  •*["  and  evaluates  to  a 
vector. 

<X VECTOR 

|nj  jfcnj>  creates  an  implicit  vector  of  length  the 
value  of  | n |  with  entry  i  initialized  to  CJfcni  i>. 

<define  ivector  <product  vector  vector  fn  fl 
[[i  <thru  1  ,n>]  [<.f  .i>]]» 

<i vector 

3 

<f unction  [ij  .i» 


evaluates  to  [  1  2  3]. 

<ITUPLB 

JnJ  ifcn|>  creates  a  definite  tuple  of  length  the 

value  of  Jni  with  entry  i  initialized  to  <|fcnj  i>.  A  definite  tuple 

can  only  be  created  as  the  initial  value  of  an  identifier  in  a 

declaration,  as  an  eleaent  of  a  definite  tuple,  or  as  an  argument  to  a 

function. 

CiaDEFIHITE 

type  [-declarations-] 

[ -for-specif ications- 
[-^,,EXIT,,  iout-na»e|] 

£ -•"ADJOIH*  J expression |  ]] 

-body-> 

creates  an  indefinite  tuple  by  setting  up  a  for  loop  in  which  the 
elements  of  the  tuple  are  generated  eleaent  by  eleaent  such  that 
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condition  is  net.  in  indefinite  tuple  can  only  be  created  as  the 
initial  value  of  an  identifier  in  a  declaration,  as  an  eleaent  of  a 
definite  tuple,  or  as  an  arguoent  to  a  function.  An  indefininte  tuple 
is  a  good  way  to  pass  arguaents  which  are  generated  increaentally  at 
run  time.  Ho  tuples  aay  be  declared  in  -declarations-.  Evaluating 
<« Jout-naae |>  will  cause  IHDEFXHITB  to  return  with  the  tuple 
generated . 


indefinite  .  ,  , 

[£!=fix  [i  1]]] 

{"declare  i  to  be  a  fixed  point 
nuaber  initialized  to  1" 
££~*"inc"  i  ^"tfcru"  .n] 

{"increaent  i  thru  .n" 

£ -."adjoin"  .i] 

;"each  tiae  through  the  loop  adjoin  the  value- 
of  i  to  the  tuple"  ] 

{"the  body  of  the  loop  is  eapty"> 


evaluates  to 


[  1  2  3  4 ]  if  the  identifier  n  has  the  value  4 

<U  NS  Hi  HE 

| x |  |tail-of-xj>  creates  a  copy  of  the  value  of  Jx|  at 
the  top  level.  The  value  of  jtail-of-x|  aust  be  obtainable  froa  the 
value  of  |x]  by  repeatedly  applying  the  function  BEST.  The  value  of 
the  function  UNSHABE  is  egual  to  its  arguaent  but  it  is  not  identical. 

<unshare  £  1  x  (y  2.0)  ]>  evaluates  to  £  1  x  (y  2.0)] 
<prog  ££  vector  £x  £a  (4)]]]] 

<is?  <**  <2  .x»  <2  < unshare  .x»»  evaluates 


to  true. 


<Y  EC TO  B ! -COB  STB  OCTOB 
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-values- >  constructs  a  vector  of  -values-.  It  is 
equivalent  to  (-values-]!. 

4.5. 1.2. 1. 1.3  String 

<ST8ING ! -CCNSTBUCTOB 

-values->  constructs  a  string  of  the  -values-. 
<string 

■Bun" 

*  H 

"Dick" 

M  It 

"run" 

!"  •> 

evaluates  to  "Bun  Dick  rnn." 

4.5.  1.2.  1.  1.  4  Graph 

<HCDE!-CC»STBnCTOB 

-properties->  constructs  a  node  with  -properties-. 

<SBABE 

Inode]  |indicatorl  |locative|>  will  cause  |nodel  to 
share  the  location  under  | indicator]  vith  the  location  ]locative|. 
The  function  share  is  due  to  Peter  Bishop. 

4.5. 1.2. 1. 1.5  Class 

<CIASS l-COHSTBDCTOB 

-elements- >  will  construct  a  class  with  -elements-. 


4.5.  1.2.  1.2  Atos 
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<ATOM! -CONST FUCTOR  |string|>  is  the  ato»  on  the  toot  oblist 


with  print  name  Jstringl. 

<ATOH ! -CONST BO CTOR 

Jstringl  lpathj  ▼uot-£ound+>  is  the  ato»  with  the 
print  name  istringl  in  the  |path|  of  oblists.  If  the  optional 
argument  +not-found+  is  not  present  and  there  is  not  atom  on  Ipath] 
with  print  name  Jstringl  ther  a  new  atcn  is  created  in  <1  |path|>. 

<PNAH£ 


string. 


|atom(>  is  the  print  name  of  ]atom|  which  is  a  uningue 


<pname  hellol-dolly! ->  is  -•’•hello" 


4.5. 1.2. 1.3  Word  and  Humber  Functions 


<BITS 

|sj  1 p 1 >  defines  a  field  of  |sj  bits  that  is  |p|  bits 
from  the  right  end  of  the  word. 

<SIGNED-BITS 

JsJ  | p J >  defines  a  signed  field  of  )s|  bits  that  is 
| p|  bits  from  the  right  end  of  the  word. 

<BITE 

|s  |  Jp J  Je|>  returns  a  byte  pointer  to  the  byte  of  ls| 
bits  that  is  |p|  bits  from  the  right  end  of  the  word  pointed  to  by 
|e|. 


<1 NC 1-PEBSISTE NT 
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Ivarj  Jdelta|>  increments  the  value  of  the  identifier 
JvarJ  by  |delta|  and  stcre  the  result  in  tvarl.  The  body  of  INC  will 
be  »n  a  separate  lexical  block  so  that  identifier  collisions 

cannu  occur. 


!%<block  (<oblist  inc!->  <oblist>) > 

<define  inc  <f unction  [*x] 

<_  :.x  <♦  ..x  1>>>> 

!%<end-block> 

<INC! -TENTATIVE 

lvar|  |deltaj>  is  like  EEC  except  that  |var|  is 
restored  in  backtracting . 


IXCblock  (<oblist  inc!->  <cblist>) > 
<define  inc! -tentative  <function  [*x] 

< _ .x  <♦  ..x  1»» 

I  JKend-block> 


<DEC 1-FERSISTENT 

|var|  |delta|>  decrements  the  value  of  the  identifier 
Jvarj  by  |delta|  and  store  the  result  in  JvarJ. 


!%<block  (<ofclist  dec!->  <oblist>)> 

<define  dec  <f unction  [*x] 

<_  :  .x  <-  ..x  1>>» 

!  *<end-block> 

<DEC!-TENTATIVE 

|var|  |delta|>  is  like  DEC  except  that  lvar|  is 
restored  in  backtracting. 

!%<blcck  (<oblist  dec!->  <oblist>) > 

<define  dec!-tenta  ti  ve  <fui»ction  £’x] 

<  .x  <-  ,.x  1»» 
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!*<end-block> 

<ASCEHDING? 

-eleaents->  is  true  only  if  -eleaents-  are  in 
ascending  order.  The  function  ASCEHDIBG?  is  due  to  Gordon  Benedict. 


<define  ascending?  <function  out  [ -«"rest"  x] 

<cond 

[<is?  <eapty>  .z> 

<.out  -»"true">] 

[  ‘‘"else*1 

<repeat  [ ] 

<c-jnd 

[<is?  <eapty>  <rest  .  x» 
<.out  -«*,true',>] 
[<not?  <is? 

<greater  <1  .*» 
<2  .^»> 

< .out  <»]> 

<chop  x»]»> 


<DESCEBDIHG? 

-eleaents- >  is  true  only  if  -eleaents-  axe  in 


descending  order. 

<IDI?IDB 


(dividend!  -divisors->  coaputes  the  |guotient|  and 
Ireaainderl  of  the  J dividend!  divided  by  the  -divisors-. 


[a  !  {idivide  7  3U  69]  evaluates  to  [a  2  1  69] 
<call 

<idivide  11  4> 

^function  [q  r] 

<print  • g> 

<print  .r»> 

;"prints  2  and  then  prints  3" 


<♦ 


-nunbers->  is  the  sun  of  -nuabers- 
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<+3  4  -5>  is  2 

<* 

-numbers->  is  the  product  of  -numbers-. 

<*  5  6>  is  30 

<ABS 

1  n | >  io  the  absolute  value  of  Jn|. 

<abs  -3>  is  3 

<£XPT 

] base |  |exfonent|>  is  exponentiation. 

<expt  2  3>  is  8 

<- 

jsubtrahendj  -subtractors- >  is  |subtrahnd|  less  - 

subtractors-. 

<-  3  2)  is  1 
<-  -5>  is  5 
<-  3  9>  is  -6 

</ 

|dividend|  -divisors->  is  the  floating  point  number 
jdividendj  divided  by  -divisors-. 

</  4>  is  .5 
</  12  3>  is  4. C 
</  3  2>  is  1.5 
</  30  2  5>  is  3.0 
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<fl»X 

-values- >  is  the  aaxiaua  of  -values-. 
<aax  -3  <♦  4  .  1>  4>  is  4.1 


<BIH 

-values->  is  the  ainiaua  of  -values-. 


4. 5. 1.2. 1.4  Algebraic 


<!♦ 

-teras->  constructs  the  sua  of  the  teras. 


<!  ♦ 

«<*  <exDt  x  2>  3> 

3 

»<♦  2  x> 

•<*  4  *> 

4 

*<expt  x  2»  evaluates  to 

<♦ 

7 

<*  6  x > 

<*  4  <expt  x  2»> 

<!♦ 

-factors- >  constructs  the  product  of  the  factors. 


<5*  3  <!*  x  2>  <!♦  x  -2>  x>  evaluates  to 
<♦ 

<*  3  <expt  x  3» 

<*  -12  x» 
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4.5.  1o  2*  1.5  L* . i? c 


<IH 

]locationj>  returns  the  contents  of  | location)  as  its 

value. 

<prog  [[*  1]]  <in  <at  x>>>  evalutates  tc  1 

<GE«hCC 


J x | >  generates  a  nev  location  (which  is  not  on  the 
stack)  holding  the  location  of  jx|. 

<in  <genloc  _>>  evaluates  to  3 
<POTLOC !~P EB  SI STENT 

1 location l  J value j>  stores  the  j value |  in  the 
(location |  and  return  the  lvalue).  It  is  equivalent  to  <_  Csaash 
|location|>  fvaluep. 


<prog  [xj  <putloc  <at  x>  1>>  assigns  x  the  value  1 
<PUTLOC! -TENTATIVE 

5.  ationj  J value) >  is  exactly  like  POTLCC  except  that 
| location)  is  rc  ired  on  backtracking. 


<defi»'t  putlocl- tentative  <function  [location  value} 
cailpoint 

[[save  <in  .location>]] 

<putloc  .location  *value> 

[  -'"optional"  ] 

<put.loc  .location  .save»» 


<VilOE 


| theta)  j bindings )>  is  the  value  of  the  identifier 


which  is  the  value  of  J theta) 
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<prog  [[-^"special"  [x  111  [y  .xl] 

<value  ,y>>  evaluates  to  1 

4.5. 1.2. 1.6  Stack 

Stacks  obey  a  last  in  first  out  storage  discipline. 

<STACK 

♦checker ♦>  returns  the  name  of  a  newly  created  stack 
to  store  eleaents  of  the  appropriate  *checker4. 

<PCSH 

JstackJ  -values- >  pushs  the  -values-  onto  the  (stack |. 
The  value  of  PUSH  is  (stack). 

<POP 

(stack |  (nuaberj  ♦not-found*>  pops  |nuaber|  eieaeats 
off  (stack),  and  returns  then  as  the  values  of  POE.  The  eleaents 
coae  off  in  the  opposite  order  they  vent  on. 

(1  !  {pop 

<push  <stack>  a  b  c  d> 
e!})  evaluates  to  (1  d  c  b). 

4.5.  1.2. 1. 1  Bing 

Elsents  can  be  inserted  and  reaoved  froa  either  end  of  a  ring. 
<BISG 

♦checkers  returns  the  nave  of  a  newly  created  ring  to 
store  eleaents  of  the  appropriate  type. 


<PBOHT 
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|ring|  jnuaberj  ♦not-found+>  returns  the  front 
JnuMberJ  eleaents  cf  jringj. 

<8EAB 

jringj  jnuaberj  +not-found*>  returns  the  rear  |nunber| 
elaents  of  lring{. 

CINSEBI-PBONf 


J ring  |  -values- >  inserts  -values-  into  the  front  of 

Jring  | . 

<1 NSEBT-BEAB 

Jring |  -values>  inserts  -values-  in  the  rear  of 

Jriug i . 

<DELBTE-F8CNT 


Jring |  jnuaberj  +not-foundO  deletes  |nuaber|  eleaents 
froa  the  front  of  jringj  and  returns  then. 


[a 

£a 


1  2 

3  2 


[a  i {delete-front  <insert-rear  <ring>  1  2  3>  2!}  b]  is 

b] 

[a  I  Jdelete-rear  <insert-rear  <ring>  1  2  3>  2!)  b]  is 

b  ]. 

<DELETE-BEAB 


lringj 

froa  the  rear  of  Jring] 


nuaberj  ♦not-found*>  deletes 
and  returns  then. 


{ nuaberj  eleaents 


4.5. 1.2. 1.8  Character 


-V 
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<CHARACTER> 

Batches  any  character. 

<L0*E8> 

Batches  an;  of  the  twenty  six  lover  case  alphabetic  characters. 

<OPPER> 

Matches  any  of  the  tvnety  six  upper  case  alphabetic  characters. 

<DIGIT> 

Batches  any  character  ihich  is  a  digit. 

<AiPH  AEETIO 

Batches  any  alphabetic  character. 

<define  alphabetic 
<actor  [ J 

<either  <lover>  <upper»» 


4.5.  1.2.  1.8  Inpnt-outpat 

Input-output  is  transacted  through  channels.  The  atonic  naaes 
read  in  are  looked  up  in  directories  called  obli~ts. 

CCHANHEL 

{direction}  {place}  { place-dependent {>  returns  a 
cobb unicat ion  channel  in  the  {direction!  specified  to  the  {placet 
naaed.  The  ] direction!  nay  be  either  -«"HEA£"  or  -•"PRIST". 

CCLOSB 

-channels- >  tern in at es  transactions  on  the  naaed  - 

channels-. 
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CHBSET 

-channel- >  resets  Ichannelj. 

<PRI HC 

|s|  jchannels|>  prints  jsj  (which  Bust  be  a  string  or 
charater)  literally.  It  does  not  put  guotes  around  it  or  otherwise 
translate  Jsf. 

<PBIN1 

i z |  [-channels-]  jpathj  iprint-tablej  | nacro- table |> 
prints  the  value  of  | x {  on  the  output  channels  relative  to  |path|  and 
returns  it  as  the  value  of  the  function  PRIRT.  The  various  types  are 
printed  according  to  the  print  functions  which  are  defined  in  Iprint- 
tablej.  The  function  PBI8T  aaintains  three  special  identifiers: 

PATH  f-PRIBT,  1AELEI-P8IMT,  HACHOSJ-PRIIT,  and  CHARIEIS! -PHUT.  The 
Iprint-tablej  aust  be  a  TTPI-VICTOH.  The  |nacro-table|  aust  be  a 
CHARACTER- VECTOR  which  has  entries  -»"HEVER",  -."BEGHIHG",  or 
-"ALSAIS". 


IKblock  (<oblist  print!->  <oblist>)> 

<define  prinl 

<f unction  [x  ^"optional" 

[-•"special"  [channels  .channels]] 
[-•"special"  [path  .path]] 

[-•"special"  [table  .table]] 
[-•"special"  [aacros  .aacros]]] 

«getc  <type  ,x>  .  table>  .x»> 

!X<end-block> 


The  print  function  fcr  vectors  is: 


<f unction  out  [y] 
<cond 


(<eapty?  .y> 

<priac  "[  ]"> 
<.out  .y>] 
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[-•"else" 

<princ  !"[ 

;"print  the  open  bracket  which 
will  be  closed  by  ]"> 

<repeat  [[x  .y]] 

<prin1  <1  ,x>> 

<chop  x> 

<cond 

[<empty?  ,x> 

<princ 

;  "close  the  [" 
!"  ]> 

<.out  .y>]> 

<princ  ! "  > 

;"print  a  space">]» 


<PRINT 


!xl  ] path |  1  print- table |  | channels |>  prints  a  carriage 
return  line  feed,  prints  Jx{  and  then  prints  a  space.  The  Jprint- 
tablej  aust  be  a  TIPE-VECTOB. 

<de£ine  print 

<f unction  [x  ->"optional" 

[-."special"  [path  .path]] 

[-•"special"  [table  .table]] 

[-•"special"  [channels  .channels]]] 
<princ  "  "> 

<prin1  .x> 

<princ  "  ">» 


<OBLIST>  is  the  root  cblist. 

COBLIST 

{trailer {  +not-found*>  is  the  oblist  with  the 
specified  {trailer |.  If  the  optional  arguaent  +not-found+  is  not 
present  and  there  is  no  oblist  with  {trailer!  then  one  is  created. 
<TBAILEB 

{atoa|>  is  the  n&ee  of  the  oblist  on  which  jatoaj 
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exists.  The  trailer  of  an  ate*  on  the  root  oblist  is  <>. 

<0  M 

jstringj  JpatL.>  returns  the  first  oblist  in  JpathJ  on 
which  an  atoa  with  print  name  ] string |  exists  if  there  is  one. 
Otherwise  it  returns  <>. 

<LINK 

Jatoa]  (path)  Jstring|>  creates  link  cn  the  first 
element  of  JpathJ  with  print  name  jstringj .  It  is  an  error  if  there 
is  an  aton  with  print  nane  JrtringJ  already  on  Ipath}.  Both  Ipathl 
and  {string l  are  optional. 


<prog  £ ] 

<link 

top! -middle! -bot tot 
(<oblist  je!->) 

"teb"> 

tab!-ae>  evaluates  to  top !-»iddle ! -bottom 


<B10CK 

| path | >  begins  a  new  lexical  block  where  atoms  are 
looked  up  on  jpath].  The  function  BLOCK  is  due  to  Jerry  Sussaan. 

<EHD-BL0CK>  .... 

closes  the  current  lexical  block  restoring  PATHI-BEkD  to  its  previous 
value. 

<BEADCB 

jchannelj  *not-found+>  removes  the  next  character  from 
| channel).  If  there  are  none,  then  ♦net-found*  is  evaluated. 

<HEXTCB 

jchannelj  *not-found*>  is  the  next  character  in 
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Jchannel|.  The  channel  is  not  aodified  by  HBXTCH.  If  there  are  none 
then  *not-foundt  is  evaluated. 

<READ 

(channel]  (path]  ♦not-found+  (aacrosl  (syntax|> 
returns  the  next  expression  froa  the  input  ( channel J  with  atoas  which 
are  qot  on  (path]  created  in  the  first  eleaent  of  ]path|.  The  aacro 
characters  are  as  defined  by  functions  of  one  arguaent  in  (aacros] 
which  aust  be  of  type  VECTGB-OF-CHABACTEBS.  The  arguaent  of  the 
function  is  the  aacro  character  which  triggered  it.  The  lexical 
syntactic  class  of  each  character  is  defined  by  (syntax]  which  also 
aust  be  a  CHAR ACT EH- VECTOR.  The  idea  for  the  read  tables  is  due  to 
John  white  If  there  are  no  aore  expressions  on  the  channel,  then  ♦not- 
found*  is  evaluated.  The  function  BBAD  Bain tains  special  local 
identifiers  CHAHHELI-BEAD,  PATH! -BEAD,  HCT-FGUHD1— BEAD,  MACROS  1-READ, 
and  ST  UTAH-READ,  froa  which  it  obtains  the  appropriate  inforaation. 
The  definition  of  BEAD  is: 


!%<block  (<oblist  read!->  <oblist>) > 


<define  read 

<fuaction  [-•"optional'* 

[-•"special**  [channel  .channel]] 
[-•"special"  [path  .path]] 

[-•"special" 

[ *not-found 

*<error  -»"end-of-file 


reache  d">]  ] 

[-■"special"  [table  .table]] 
[-•"special"  [syntax  .syntax]]] 
<prog  loop  [character] 

<_  :  character  <nextch» 

;"let  character  be  next  charaacter 


about 


to  be  read” 
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-•"ignore*^ 


associated 


<cond 

[<is?  <getc  .character  . syntax> 
<again  . loop>]> 

<<getc  <readch>  .  table>  .character» 
; "execute  the  read  procedare 

with  the  first  character"» 


!X<end-block> 

The  following  are  the  macro  characters  which  are  predefined  for  the 
reader: 


1 1 type |  Jobjec'  reads  1  object!  then  tries  to 
convert  it  to  re  a  |type|. 

For  exaaple  tcoaplex  [3  4]  will  attempt  to  convert  [3  4]  to 
type  coaplex. 

! 9FALSE  is  the  unigue  object  FALSB. 

! #NODE  ♦rest-index*  [-properties-]  where  each 

Ipropertyl  is  cf  the  fora  [lindicatorl  | value j  ]  is  a  node. 

JiPBOPEBTIES  (object |  [-properties-]  where  e«.ch 
Ipropertyl  is  of  the  fora  [(indicator!  | value!] 
is  an  object  with  properties. 

I9AEC  [lobject]  JindicatorJ]  is  a  arc  from  lobjectj 
with  naae  JindicatorJ. 

1 1  character]  is  read  as  a  single  character. 

The  I  serves  as  an  escape  for  characters 
which  cannot  be  input  directly. 

!!  is  the  exclamation  character. 

This  is  the  only  way  to  get  in  the  character  !. 

Xjforaj  reads  iforaj  evaluate  it  and  use  the  value  as  the 
expression  read. 

The  X  aacro  is  due  to  Chris  Reeve. 

!X|foral  reads  JforaJ  evaluate  it  and  then  pretend  that 
what  was  actually  read  was  the  null  string. 

The  IX  aacro  is  due  to  Chris  Reeve. 

The  aacro  character  IX  enables  us  to  have  side  efrects  while 
reading. 

For  exaaple: 
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!%<block  |path|>  causes  the  reader  to  read  the 

subsequent 

it  ess  into  jpathi  until  the  Batching  ! *<end-block>  is 
encountered. 

$  terminates  ccaaands. 

"(string!"  is  a  character  string. 

!w | character |  is  a  single  character. 

€  | character J  reads  (character)  as  though  it 
were  not  a  special  character. 

In  other  words  * (character!  is  an  ordinary 
alphabetic  character  to 

the  literal  reader  as  though  <getc  (character)  (syntax(>  were 
-•"alphabet  ic". 

(-elements-)  is  a  list. 

The  read  function  for  !K(  is: 

<f unction  (cl 

;"the  value  will  be  a  list" 

<list 

(indefinite  [x] 

; "construct  a  tuple  of  indefinite  size 
■ade  out  of  the  values  of  x" 
[[-"adjoin"  .xl 
[-"exit"  out]] 

<call 

<read> 

<function  [-"rest"  t] 

<cond 

[<is?  <length  .t>  2> 

;"read  has  returned  with 
two  values" 

<rule  [ ]  <1  »t> 

[; "first  of  .  t  watches  (" 
!") 

;"the  first  value  xs 

a  right  paren" 

<vOUt>] 

-"else" 

<error 

"aisiatched 


[-"else" 

<_  :x  <1  .t»]»>)» 


left"»] 
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The  read  function  for  !M)  is: 

<function  out  [cj 

;"exit  with  two  values  so  that  any 
function  which 
calls  this  one  will  know 
sonething  is  fishy” 

<.  out 

;"this  should  match  (" 

<>» 


[-elements-]  is  a  vector. 

![ -elements- !  ]  is  a  homogeneous  vector. 

The  notation  is  due  to  Cnris  Beeve  and  Gerry  Sussman. 

<-elements->  is  an  element  fori. 

{-elements-}  is  a  segment  form. 

I {-elements- !}  is  a  multiple  value  segment  fora. 

| {form |  is  # ALIOH-PAHALLEL  ]fora|. 

! ] ] form |  is  #ESSEHTIAL-PAH ALLEL  {form!. 

{atom]!-  forces  Jatoal  to  be  read  into  the  ROOT  oblist. 

I  atom]  !-{ trailer  1  reads  (atom)  into  the  oblist  with  |trailer|. 
If  the  following  is  typed  in: 

<prog  [  ] 

foo!-thesis!- 
bac!-preface!-thesisS-'  • 

IJKblock  (<oblist  preface 2 -thesis !-> 

<oblist  thesis!->)> 

(mumble  hellol-  foo  bar  3  thesis  preface) 

J  *<end-block» 


then  it  will  evaluate  to 

(a umblel- preface !- thesis 
hello 

fool -  thesis 

bar ! -preface! -thesis 

3 

thesis 

preface! -thesis) 
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(-expressions-  (eleeentj  ;  (coaaentl  -Bore-expressions-) 
The  read  function  for  I";  is: 

<fuuction  out  [character]  <.out  l";  <read»> 

(-expressions-  (eleaentl  !;  (intent |  -aore-expressions-) 
The  read  function  for  l"!;  is: 

<f unction  out  [character]  <.out  l"!;  <read>» 


The  following  prefix  aacro  characters  are  predefined. 


* (expression j  is  <QDOTB  }e  pression|>. 

The  *  aacro  is  due  to  John  White. 

The  read  function  for  the  character  •  is: 

<function  [character]  !'<guote  <read»> 

!*Jfora(  is  <S0PPBESS  |fora]>  which  suppresses  invocation 
of  Jforaj. 

The  read  function  for  !"!*  is  : 

<f unction  [character]  !  *<suppress  <read»> 

-'lvalue!  is  a  unigue  copy  pf  JvalneJ. 

Tne  read  function  for  !"-»  xs: 

<f unction  [character]  <uniguize  <read»> 

S-»|value(  is  <UHIQ0IZE  lvalue(>. 

The  read  function  for  I*!-*  is: 

<function  [character]  !*<uniguize  <read»> 

!=|atoa |  is  <0?-TTPE  (atoa(>. 

6  j  fora  \  is  <GAIE  }fora(> 

!t<-eleaents->  is  <TIHJ0BA1X  <-«leacnts-» 

It  (-ele aents-]  is  [TEBBQBiBY  <-eleaents->} 

!s<-eieaents->  is  <STBAIGRTE3  <-eleaents-» 

Is  {-eleaents-1  is  {STBAIGBTEB  <-eJeaent.7->] 

!p<-eleaents->  is  <PEBSISTEBT  <-eleaents-» 


Ip  {--eleaents-j  is  {PEBSISTEHT  <-eleaents->} 
The  lacro  characters  It  Is,  and  Ip  are  due 
to  Peter  Bishop. 
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. (identif ier l  is  <VAIUI  (identif ier ( >. 

I. J identifier!  is  {VALUE  {identifier J} . 

,  {identifier |  is  <GLCBAL  { identifier^ 

!, (identifier!  is  {GLOEAL  {identifier}. 

_1 identifier!  is  <ALTEB I -TENTATIVE  (identifier {>. 

S_J identifier (  is  {ALTEBl-TENTATI VE  (identifier!}. 

: | identifier!  is  <ALTEB I -PEBSISTEHT  (identifier (>. 

I:  (identifier!  is  {ALTSB  I- PEBSISTEHT  (identifier!}. 

?( identifier!  is  <GIVEB  J identifier (>. 

I? (identifier}  is  {GIVEN  {identifier!}. 

4.5. 1.2.2  Protection 

CUHPBCTECT 

jxj  ( u ] >  allows  access  to  the  object  x  according  to 
the  use  | u j  which  aa j  be: 

-•"write’'  for  write 
-•"execu*  ?"  for  execute 

Restricting  the  access  of  a  piece  of  data  ensures  that  it  can  not  be 
used  for  a  purpose  which  was  not  intended.  For  exaaple  it  can  be  used 
to  insure  that  checking  routines  do  not  aodify  the  data  which  they  are 
supposed  to  inspect  for  errors. 


<PBOTEC? 
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jxj  I u I >  restricts  the  uses  to  which  ] x ]  way  be  put  by 
not  allowing  the  use  ]u|  which  nay  be  -•"REID”,  -•"PUT",  or  -»"H8ITE. 

The  use  -•"PUT"  protects  against  putting  on  non-nuserical  indicators 
whereas  -»"HRITE"  protects  the  numerical  indicators. 


<put 

<2  <protect  (a  (3  4))  -•"write"» 

[  1  a  ]>  causes  a  write  protection  error 

<rest  <protect  (a  2  b)  -•"vrite"»  returns  (2  b)  with 

write  protect 


PROTECTION 


access  for  j  x | • 

[-•"write  ] 


| x ] >  returns  a  vector  of  the  protection  nodes  of 


protection  <rest  protect  (a  2  b)  -•"vrite"»>  is 


4.5. 1.2.3  Monitoring 

<8081108 

]1]  J f l  ]u]>  aonitors  the  location  ]1|  with  the 
function  Jf|  for  the  use  |u|.  The  use  aay  be  a  list  of  *ny  of  the 
following: 

-»"8E4D"  for  read 
-•"EXECUTE"  for  execute 
-•"  WHITE"  for  write 

If  a  process  attewpts  to  used  a  nonitored  location  then  <f  Hi  |u| 

J x 1 >  is  evaluated.  If  a  write  operation  is  being  atteapted,  then  x  is 
the  value  which  is  being  stored.  If  a  execute  operation  is  be.4ng 
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completed  for  a  £unct.:cn,  then  x  is  the  tuple  of  values  being 
returned.  If  an  execute  operation  is  being  c  -mpleted  for  an  actor, 
then  x  is  the  object  that  was  latched,  Monitoring  is  implemented  in  a 
way  that  is  logically  equivalent  to  creating  a  arc  from  the  location 
Jl|  to  the  list  of  monitors  for  the  ..ocation  |1|  under  the  indicator 
MC'NITOES.  Dave  heed  invented  the  lore  efficient  xethod  that  is 
actually  used.  Monitors  are  useful  for  implementing  various  kinds  of 
procedural  data.  For  exaaple  they  are  used  to  implement  break  points 
in  the  language.  The  following  procedure  will  Bake  a  list  (called 
history-of-x)  of  all  the  values  that  are  stored  into  the  special 
identifier  x. 

<Bonitcr 

<at  x> 

<f unction  [lav] 

<  : histoi:y-of-x  („v  !  .history-of-x)  » 

->"write"> 

Hext  we  would  like  to  describe  how  monitors  can  be  used  to 
implement  an  idea  due  to  Peter  Landin  which  he  calls  a  streai.  The 
idea  is  that  the  element  .  of  a  list  should  be  able  to  be  dynamically 
computed  instead  of  all  of  them  having  to  be  computed  at  once.  For 
example  in  debugging  the  elements  of  a  list  might  be  computed 
incr<;*entall y  as  they  are  jeeded  by  being  input  from  a  teletypewriter, 
ie  could  construct  such  a  list  |i(  w  follows: 

<monitor 

(0) 

;"the  0  is  a  dunmy  vhicb  wit? 

be  replaced  with  the  first 
element  read" 


Mere  we  define  f  by: 


<define  f 

<£unction  [1 

<«onitor 


u  v  ] 


<rest 


< 


;"aonitor  the 
-,«read">» 


(v replace  <read» 

{replace  (0)}) 

.1» 

rest  of  the  list  with  f" 


Mow  <1  | 1 | >  is  the  first  expression  read,  <2  | 1 | >  is  the  second,  etc. 
<UMHOHITOa 

Jl{  ipat{>  unaonitors  the  location  |1|  by  all 
functions  that  natch  JpatJ. 


M.5.1.2.4  Type 


<RETBACT 

|xj>  returns  the  value  jxj  retracted  to  the  type  in 
which  it  was  defined.  The  function  RETRACT  is  the  identity  function 
on  objects  of  priiitive  type. 

'STORAGE 

|x 1 >  returns  the  primitive  storage  allocation  type  of 
]2|.  The  primitive  storage  types  are  LIST,  TECTOB,  STBISG, 

SO HOG E BOOS— YECTCB,  STACK,  RIB G,  ATOB,  ACTIVATION,  JOBCTICB,  LABEL, 
PROCESS,  and  BOOK. 


<Tf  PE 
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| x J >  returns  the  dynaaic  type  of  |x). 

CCECLASED 

] x | >  returns  the  declared  attributes  of  jx).  The 
function  DECLABBD  is  useful  in  deciding  how  to  expand  aacros. 

<GETC 

Japparent- indicator!  J object)  ♦  not-foucdO  gets  the 
| apparent- indicator |  coaponent  of  Jobject)  according  tc  the  structure 
definition  for  <TY  |object|>. 

<ATC 

lappareat-indicator)  j  object)  +Bot-found*>  returns  a 
locatiae  to  the  {apparent-indicator)  ccaponent  of  Jobject)  according 
to  the  structure  definition  for  <TYPE  |object)>. 

<PUTC! -PEBSISTEHT 

Jcbject)  -properties->  puts  -properties-  on  |object| 
according  to  the  structure  definition  for  <TYPE  |object)>. 

<PtJTC  !-TEHTlTIf  E 

Jobject)  - properties->  is  eractly  like  POTC  except 
that  the  properties  of  Jobject)  are  restored  on  bac  racking. 


4.5. 1.2.5  Synchronization 
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CLOCK 


-lock-specif ications->  atteapts  to  satisfy  the  -lock- 
specifications-  where  each  lock-specification  aust  be  cne  of  the 
following: 

llocationj  aeans  that  Jlocationl  is  to  be  locked  if  it  is  not 
already  locked. 

i-»"RELCCK"  Jlocationl]  a^ans  that  (location)  is  to  be  relocked 
wen  if  it  xs  already  locked. 


[ -•’’UNLOCKED0'  Jlocatiiia)]  aeans  that  llocationj  aust  be 
unlocked. 

The  process  which  calls  the  function  LOCK  is  suspended  until  all  the 
lock-specifications-  are  satisfied.  Suppose  that  we  have  a  data  base 
that  so aetiaes  is  aoaentarily  in  aD  inconsistent  state  while  it  is 
being  aodified.  He  would  like  to  set  up  locks  so  that  arbitrarily 
■any  processes  can  be  reading  the  data  base  at  one  tiae  but  only  one 
process  can  aodify  it  at  a  tiae.  Suppose  that  each  data  base  has 
BE1DI0CK  and  a  HRITELOCK  coaponent  in  addtion  to  a  C08TEHT  coaponent. 

<define  read-data-base  <function  rdb  [data-base] 

<prog  [current-content  ] 

<lf  ok 

[  -."unlocked* 

<atc  writelock  .data-base>] 
[-."re  lock" 

<atc  readlock  . data-base>  ]> 
;"in  order  to  read  the  data  base 
the  writelock  aust 
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<define  write-data-base 

<f unction  [data-base  new-content] 

<lock  <atc  writelock  .data-base» 

<lock  <atc  readlock  ,data-base>> 

;"in  order  to  write  the  data  base  the 

writelock 

■usi  be  locked  and 

then  readlock  aust  be  locked" 

<putc  .data-base  [content  .new-content ]> 
Cunlcck 

<atc  writelock  .data-base> 

<atc  readlock  .data-base» 

;"is  done  after  the  process  stops  writing"» 


<LCCKEB 

♦checker*  ♦activation- nane*  [-lock-specifications-]  - 
body->  where  the  ♦activation-naae*  a  ♦checker*  are  optional  attempts 
to  achieve  -lock-specifations-  execute  the  -body-  and  then  unlock  any 
locations  that  were  locked  by  -lock-specif ications-.  The  function 
LOCKES  eakes  use  of  CATCH  to  insure  that  the  locks  are  unlocked  when 
*activation-nane+  is  exited.  Be  can  do  the  above  exaaple  as  follows: 


^define  read-data-base  <function  [data-base] 

<lecker  [  ] 

[( -•"unlocked" 

<atc  writelock  .data-base>] 
[  -t"relock" 

<atc  readlock  .data-base>]] 
<g®tc  content  .data~base»» 

<defiae  write-data-base 

<f unction  [data-base  new-content] 

<locker  [ ] 

[<atc  writelock  .data-base>] 
docker  [ ] 

[<atc  readlock  .*ata-base>] 

<putc 

•data-base 

[content  .new-ccateat  ]»»> 


CLOCKED? 


-locations- >  at?  vapts  to  lock  the  locations  which  are 
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arguments.  If  the  locations  cannot  be  locked  then  the  function 
LOCKED?  returns  <>. 

CUILOCK 


-locations->  unlocks  the  locations. 


4.5. 1.3  Debugging 
<EBBOB 


Inessa ge | >  vill  type  out  the  aessage  and  go  into  an 


error  loop. 


!%<block  (<oblist  error! ->  <oblist>) > 

<de£ine  erpor  <function 

[Vcptxonal"  [message  Vnone"]] 

<print  (Verr  or- message:"  .message)  ,console> 

Sprint  the  aessage  on  the  console  channel" 

<repeat  [Vspecial"  loop] 

[[old-cut  .out] 

;"save  the  old  value  of  out  in  old-out" 

[Vspecial"  [culprit  <frane  3>  ]  ] 

;"the  culprit  activation  is  the  one  three  frames  back’* 
viabels" 

[-."special"  [out  <f unction  [ -^"optional"  [n  1]] 

;"the  label  procedure  out  handles 
exits  from  error  loops" 

<cond 

[<is?  <less  1>  .n> 

<&gain  .loop>] 

[-."else* 

<. old-out  <-  .0  1»]»]J] 

<print  <eval  <read»>»> 

!S<end-block> 


<DEB0G 


{status i>  vill  set  the  state  of  the  debug  state  to 
.  "he  status  may  be  Von"  or  Voff". 


{status] 
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<BINDINGS 


| p | >  is  the  current  set  of  bindings  for  the  process 


IPI  • 

<FBA8E>  is  the  current  activation  fraae  of  the  process  which 
calls  it. 


<FB£ HE  )  place  |>  the  last  activation  of  (place)  if  (place) 
is  a  process  and  is  (place)  if  (place)  is  an  activation. 

<FBABE 


(place)  1 n | >  is  the  activation  fraae  which  is  )n| 
fraaes  back  frca  (place). 

<PB0CEDU3E 


]fraae(>  is  the  pzocedure  of  (fraae). 

<8ABE 

J procedure] >  is  the  naae  of  {procedure!  if  it  has  one 
and  <>  otherwise. 


<PB0CH1BE 

|fraae(>  is  the  naae  of  the  procedure  for  (fraae).  It 
is  equivalent  to  <RABE  <PB0CI!)08E  Jfraae(>>. 

<AHGS 

)fraae]>  is  the  tuple  of  arguaents  of  )fra«e|. 


4.5.  1.4  Identifier 


<ASSIGRED? 


(var)  |b(>  is  true  onlj  if  the  identifier  (var)  has 
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been  assigned  a  value  within  the  bindings  )b|. 

<0H&SS1GN 

tvar]  |b]>  Bakes  {vac|  unassigned  within  the  bindings 

|b|. 

<BOUHD? 

jvarj  1 b | >  is  true  only  if  the  identifier  Jvarj  is 
bound  within  the  bindings  )b|. 


4.5.2  Eraaples  of  the  Use  of  Functions 


The  function  factorial  is  defined  below  in  order  to  illustrate 
the  syntax  of  functiors  that  produce  values.  On  entrance  to  REPEAT, 
temp  is  immediately  bound  to  1. 


<define  factorial 

<f unction  factorial  [n]  <repeat  [[teap  1]] 

<cond 

[<is?  <less  1>  .n> 

<. factorial  ,teap> 

;"exit  .factorial  with  *teap"]> 

<_  :teap  <*  ,n  ,teap» 

<dec  n»>> 

Using  a  for  statement,  we  can  define  factorial  as  follows: 


<define  factorial 

<f unction  fact  [n] 

<f  or 

[[ temp  1 

[[-."dec"  n  -•"thru"  1] 

[“•"final" 

<.fact  .teap> 

;exit  .fact  with  .teap"]] 
<_  :teap  <*  .n  .teap»»> 
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Thus  the  value  cf  <factorial  3>  is  6;  and  the  value  of  <factorial  <* 
2  2»  is  24 
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4.6  Actors  in  Patterns 


Examples  of  actors  are  VEL  for  disjunction,  MCR  for  negation, 
ALL  for  conjunction,  and  STAB  for  Kleene  star  in  general  regular 
expressions.  He  use  the  characters  {  and  j  to  delinit  actor  calls 
that  are  to  natch  as  segaents. 


<prog  [a  b  c  ] 

;"we  are  inside  a  progran.  we  have  declared  the 
identifiers  a  b  and  c. 

In  the  assignment  statexent  below  the  pattern 
(k  {all  _a  _b)  _c)  is  natched  against 
(k  x  y  z). 

The  pattern  {all  _a  _b}  Batches  an  expression 
only  if  bo*.o  _a  and  _b  natch  the  expression. " 
<is?  (k  (a-..'  „a  _bj  _c)  (k  x”y  z) » 
a  gets  the  .aloe  (x  y) 

b  gets  the  value  (x  y) 

c  gets  the  value  z 

<prog  [i  cl 

<is?  (l_x  {either  (th)  (tv)}  !_c)  (a  o  tw  th) » 
x  gets  the  value  (a  o) 

c  gets  the  value  (th) 

<prog  [xl 

vis?  ( {star  aj  _x)  (a  a  a  a)  >> 
x  gets  the  value  a 

The  argunent  of  the  actor  HHEI  is  a  list  of  clauses.  If  the  object 
that  the  actor  HHEH  is  trying  to  natch  has  the  property  that  it 
Batches  the  first  eleaent  of  one  of  the  clauses  then  it  Bust  natch  the 
rest  of  the  clanents  is  that  clause. 


<prog  [[ !*fix  x J) 

<is?  <vhen  [<?>  _x]>  3» 

x  gets  the  value  3  since  3  is  a  fixed  point  nnnber. 
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In  the  expression  below  <all  _a  _b>  Batches  3  only  if  both  _a 
and  b  aatch  3.  Thus  both  a  and  b  are  set  to  3. 


<prog  [a  b] 

<is?  <ail  _a  _b>  3» 

A  nuaber  of  actors  are  defined  below. 

A  palindroae  is  defined  to  be  a  list  that  reads  the  s?:ae 
backwards  and  forwards.  Thns  (a  (b)  (b)  a),  {} ,  and  ((a  b)  (a  b))  are 
palindroaes.  Here  foraally  in  HATCHLESS,  a  palindroae  can  defined  as 
an  actor  of  no  arguaents: 


<define  palindroae 
<actor  [ ] 

palindroae  is  a  actor  of  no  arguaents" 

<either 

<eapty> 

;"a  palindroae  is  either  eapty  or** 
<declaration  [x] 

; "declare  a  new  local  x" 

<list  _x  {palindroae}  .x> 

;"let  x  be  the  first  eleaent  of  the 
linear  structure. 

Also  x  anst 
be  the  last  eleaent 
with  a  palindroae 
in  between"»» 


For  exaaple 

<is?  <palindroae>  {a  1  1  a) >  is  true. 

The  fora  ACT OB  is  like  the  function  of  LISP  except  that  it  is  used  in 
actors  instead  of  in  functions.  The  above  definition  reads:  a 
palindroae  is  a  list  or  vector  such  that  it  is  eapty  or  it  is  a  list 
or  vector  which  begins  and  ends  with  x  with  a  palindroae  in  between. 
The  actor  SAHE  causes  the  identifier  x  to  be  rebound  every  tiae  that 
palindroae  is  called.  The  actor  ^^VBKSE  is  defined  to  be  snch  that 


*!*»  «. 


if.  ic  r"t 


FORMAT  OF  ACTOR  ACTIVATIONS 
IN  SNAPSHOTS 


IDENTIFIER-BINDINGS 


|  BINDINGS  | 

I _ I 

NOTE  :  THE  I DENTIFIER  -  BINDINGS 

AND  RETURN-CONTROL  POINTERS 
OF  AN  ACTIVATION  ARE  USUA»  LY 
THE  SAME  AND  THUS  ARE 
COMBINED  INTO  A  DOUBLE 
POINTER  LIKE  THIS. 


BACK 

TRACK 

CONTROL 


APSHOT  NO. 
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<is?  <reverse  .x>  .y>  is  true  only  if  the  value  of  x  is  the  reverse  of 
the  value  of  y.  The  definition  of  reverse  is 


<define  reverse 

<actor  [ x] 

<when 

[ <nonadic> 

;wif  the  object  being  aatched  is  aonadic 
then  it  aust  l «?  egual  to  x" 

•*] 

[ <declaration  [first  rest] 

; "otherwise  let  first 

be  the  first  element 
of  the  Batching  object 
and  rest 

be  the  segaent  of  the  rest  of 
the  eleaents  of  the 
Batching  object. " 

<linear  _f irst  ! _rest> 

;"vhen  <linear  (reverse  .rest}  .first> 
Batches  . z  we  are  done" 

<be  <is? 

<linear 

(reverse  .rest} 

.f irst> 

,x>»  ]»> 


For  ezaaple 

<is?  <reverse  (x  y  z) >  (*  y  x) >  is  true 

Hany  of  the  ideas  for  the  actors  coae  froa  Post  productions , 
BIF ,  general  regular  expressions,  BLIIST  (Slagle's  algebraic  pattern 
aatcher),  SROBCL,  COIBIBT,  and  LISP.  Be  give  exaaples  of  the  use  of 
these  actors  afterward. 


4.6.1  Definitions  of  ictors 
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4.6. 1.1  Control  Actors 


4.6. 1.1.1  Conditional  Actors 
<== 


] x | >  Batches  an  object  only  if  the  value  of  |x|  is 
identical  to  the  object. 

<HON 

(pattern ]>  Batches  an  object  only  if  |pattern|  does 
not  natch  the  object.  Thus  <non  c>  Batches  a,  but  <non  a>  does  not 
Batch  a. 

<VBL 

-patterns- >  Batches  an  object  only  if  scie  pattern  in 
turn  Batches  the  object.  If  a  staple  failure  backs  up  to  the  actor 
?EL,  then  the  next  alternative  pattern  in  turn  is  tried.  If  all  the 
alternatives  are  exhausted,  then  VEL  itself  propagates  a  siaple 
failure  backward.  For  exaapie 


<prog  [[a  3]j 

<_  (<vel  4  _a>  <♦  .a  1>)  (4  5)» 

a  is  initialized  to  3 
4  is  Batched  sith  4 
<♦  3  1>  fails  to  Batch  S. 

_a  is  Batched  against  4  giving  a  the  value  4 
<♦  4  1>  Batches  5 


<prog  [a^b  ] 

(<vel  :a  ?b>  ?a) 

(3  4)» 

a  gets  the  valae  3 

3  does  not  natch  4  so  a  siaple  failure  is  generated 
a  gets  the  valne  tnnassigued 


SNAPSHOT  NO.  1 


SNAPSHOT  NO.  2 


?b> 


>6  [a  b ] 
S  ? 


(<VEL  Pa  Pb>  Pa) 

i..  N  \ 


SNAPSHOT  NO.  3 


\ 


SNAPSHOT  NO.  4 


4.C?  it?  P 


r 
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b  gets  the  value  3 
a  gets  the  v?tlue  •* 

The  following  exanple  shows  >w  TEL  is  different  fro*  IITHEB: 

<prog  (i  bj 
<is? 

i 

<either  ?a  ?h> 

?a) 

(3  4)» 

evaluates  to  -■>  which  i false  .since  EITHER  does  not  try  Batching  ?b 
with  3  becaus.  *  sooces.  fw'.ly  Batched  3. 

<ALL 

-patterns-)  Batches  an  object  only  if  each  pattern  in 
turn  Batches  tie  object. 

<IS-ACTOB 

|pattern]>  will  natch  an  object  . .  jly  if  the  object 
Batches  the  value  of  ] patter* 1* 

<BE 

j predicate! >  Batches  an  object  only  if  the  ; predicate} 
is  not  false.  In  other  words  the  actor  BE  ignores  the  object  that  it 
is  supposed  to  natch  and  considers  only  the  value  of  predicate. 

<be  <is?  3  3»  Batches  anything 

<be  <>>  does  not  aatcb  anything  since  <>  is  false. 
CHAICHIHG 

[jobjectj  ItailJ  (locj ]  (predicate |>  is  exactly  like 


the  actor  BE  except  that  the  identifier  (object i  is  bound  to  the 
object  being  Batched,  Jtailf  ia  bound  to  its  tail  if  it  has  one,  and 
|loc |  is  bound  to  a  locative  to  (object |  if  there  is  one* 
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<HHEH 

♦checker*  -clauses->  where  each  clause  is  of  the  for* 
[jpattern]  -acre-patterns-]  or  of  the  for*  tDECLABE  [[-declarations-] 
{pattern j  -acre-patterns- ]  Batches  an  object  if  the  first  element  of 
soae  clause  in  turn  aatCijes  tie  object  and  then  the  rest  of  the 
elements  in  that  clause  match  the  object. 

<prog  [x  y] 

<is? 

<when  [<nu*ber>  _x]  f_y]> 

foo» 

;"y  gets  the  value  foo  since  foo  is  net  a  number" 

<prog  [£!=fix  [y  1]  x]] 

<is? 

<when 

£<be  <is?  x  <♦  .y  1»> 

<♦  .X  2>]> 

4» 

;"x  qets  the  value  4" 

4.6.  1.1.  2  Block  Structuring 

<D£CLA2iT10N 

[-declarations-]  -patterns->  matches  an  object  only  if 
each  pattern  in  turn  Batches  the  object  after  -declarations-  are 
bound. 

<_  «declaratioa[ [ x ]  _x  ]  4> 

x  gets  the  value  4 

C1CTITB 

<1  procedure]  -args->  ] place |>  Batches  the  pattern 
jprocedure]  against  all  the  currently  active  procedures  within 
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| place] .  If  the  natch  succeeds  then  -args-  are  aatched  against  the 

procedures  arguaonts.  The  | place |  aay  either  be  a  process  or  of  the 
fora  [ -^”BBTMEE8,,  |naae1j  Jraae2jJ  where  JnaaelJ  and  jnaae2!  are  the 
names  of  blocks  for  a  process. 

4.6.  1.2  Data  Actors 

4.6.  1.2.  1  Specialists 

4.6.  1.2.  1.1  Structure  Actors 

Any  expression  deliaited  by  " and  ") "  aatches  a  list.  Any 
expression  delimited  by  w["  and  Batches  a  vector  or  a  tuple. 

<?>  Batches  anything. 

<? 

I n | >  Batches  an  object  only  if  the  object  has  length 
the  value  of  |n|.  For  exaaple  the  following  are  true: 

<is?  <?>  (b  a  c) >  is  true. 

<is?  {{?))  ()  >  is  true. 

<is?  (a  l?})  (a)>  is  true. 

<is?  (a  {?} )  (a  b)  >  is  true. 

Something  of  the  fora  * ] x |  Batches  only  those  objects  which 
are  equal  to  ixj.  For  exaaple  '.a  aatches  .a  and  fa  Batches  a. 

<? 

in |  1  pattern | >  will  Batch  anything  of  length  |n|  which 
in  turn  aatches  |pattern|. 
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<prog  [ four- characters  ] 

<is? 

[<?  3>  <?  4  :four-elenents>  <?>] 
(a  b  c  d  e  f  g  ii  i]> 

;"f  our-elenents  has  the  value  [d  e  f  g]"> 


CSTAH 

-patterns- >  Batches  an  object  only  if  the  object 
consists  of  a  sequence  (including  the  null  sequence)  of  eleaents  that 
natch  patterns.  For  exaaple  <star  3>  Batches  {3  3  3)  and  (a  {star  b 
c}  e)  Batches  (a  b  c  b  c  e) . 

CDAGGEB 

-pat terns- >  Batches  an  object  only  if  the  object 
consists  of  at  least  one  sequence  of  eleaents  that  natch  patterns. 

For  exaaple  <dagger  3>  Batches  (3)  and  (3  3)  but  does  not  natch  () . 

<OPTIO MS 

-patterns- >  Batches  a  sequence  of  eleaents  which  Batch 
a  subsequence  of  the  patterns  fron  left  to  right.  For  exaaple 
Coptions  a  !=*fix  !=aton>  Batches  (a  3). 

<H  AS 

-properties-^  Batches  any  object  with  the  appropriate 
properties  where  each  property  is  of  one  of  the  following  foras: 


[ (indicator |  <FAIL>]  fails  if  there  is  an  object  under 
|  indicator ] . 


[ | indicator | j  teaoves  the  value  under  the  (indicator!  if  it  is 

present 


.i  [fiadica 

(indicator |  a  pi 


tor* 
see  o 


i*uu  si 


s  that  the  o 
cb  Batches  t 


M 


ect  has  under  the 
pattern  (pat). 
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The  actor  BAS  allocs  BATCHLESS  to  do  pattern  latching  cn  arbitrary 
graph  structures.  The  exaaple  of  the  syntax  of  LISP  given  beloe  shows 
how  we  can  write  graaaars  over  graphs.  The  idea  of  developing  pattern 
structures  over  graphs  has  been  generalized  and  extended  in  PLAHKEE . 

<_ 

<has  [*xM  3]  £4]  [c  <replace  5>]> 

<node  [c  [4]]  [4  5]  ["x55  5  ]» 

evaluates  to 

Anode  [["x"  3]  [c  5]J 

<  SELECT 

Ipat]  |other2>  Batches  any  structue  such  that  one  of 
the  elenents  of  the*  structure  Batches  }patj  and  the  reaainder  of  the 
structure  Batches  Jother)-. 


<prog  [r] 

<select  3  _r>  <class  4  3  5> 

;"r  gets  the  value  <class  4  5>H> 


<0F 

Ipatj  {collect]  ] other] >  Batches  any  structure  such 
that  the  list  of  all  the  eleaents  of  the  structure  that  Batch  Ipat] 
Batches  the  pattern  |coliect|  and  the  rest  natch  the  pattern  |other|. 
For  exaaple 


<prog  [integers  others] 

<_ 

<of  !=fix  integers  others> 
[a  3  b  5  9>> 

integers  gets  the  value  (3  5  9) 
others  gets  the  value  (a  b) 


<STB0CT0BE> 
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matches  an;  list,  vector,  or  node. 


<EBPTI> 


Batches  any  eapty  structure. 

<HCIAD> 


Batches  any  object  which  cannot  be  decoaposed. 


<LIHEAB 


-patterns- >  Batches  any  list,  vector,  or  tuple  whose 
elements  natch  the  patterns  in  order.  For  exaaple  <1 inear  3  4> 
Batches  (3  4)  and  it  also  Batches  £3  4]. 

<E1E BEBT 


] x | >  Batches  any  object  such  that  the  object  is  an 

eleaent  of  lx|. 


<C0BT1IHS 


Ipatp  Batches  any  structure  which  contains  an  object 
that  catches  lpat|. 


!%<block  (<otlist  contains!->  <oblist>) > 


<define  contains 
<actor 

£  *1] 

<container 

<eval  !  *<actor  ()  .y»»> 


<define  container  <actor  [x] 

<»hen 

[<.x> 

;"if  the  actor  x  Batches 

the  matching  object 
then  ve  are  done”] 

£<aonadic> 

;”if  the  Batching  object  is 
Bonadic  then  fail" 

<fail>] 

£<linear  <container  .  x>  .{?}> 
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;Hif  the  first  eleaent  iu  the 

Batching  object  contains  z 
then  we  are  done"] 

[<?> 

;*else  the  rest  of  the  aatching  object 
aust  contain  x” 

<linear  <?>  {container  .*)>]»> 


!*<end-block> 


<BEPLACE 


]zj>  Batches  an;  object.  As  a  side  effect  the  object 
which  is  Batched  is  replaced  with  the  value  of  ]x|. 


<prog  [y] 

<is? 

<all 

_7 

(<replace  a>  {replace  (b)})> 
(c  d  e)>> 

y  gets  the  value  (a  b) 

He  can  define  an  actor  rev  which  changes  any  list  which  it  Batches  to 
the  reverse  of  that  list. 


<define  rev  <actor  [  ] 

<either 

<eapty> 

<linear  <?>> 

declaration  [first  last] 

<linear  : first  (?]  :last> 
<linear 

<replace  . last> 

[rev] 

<replace  .  first»»» 


low  if  evaluate 


<  :c  (e  f  g) 

<  <rev>  .c5 


> 


then  c  aysteriously  hac  the  value  (g  f  e)  because  the  actor  rev 
destroys  the  initial  list  to  sake  the  reverse. 

<PBECZDZS 
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] x i >  will  aatch  any  expression  which  precedes  jx|  in 
the  total  ordering  on  expressions.  For  exaaple  <precedes  rc*>  will 
natch  "a"  since  "a"  prcedes  "c". 

<FOLLOBS 

JxJ>  will  aatch  an;  expression  which  follows  |x|  in 
the  total  ordering  on  expressions. 

4.6. 1.2.1. 1. 1  list 

<LIST!-DECOHFOSEB 

-patterns- >  Batches  lists  whose  eleaents  aatch  - 
patterns-.  It  is  equivalent  to  (-patterns-) • 

4.6. 1.2. 1. 1.2  Vector 

<?ECT0BI -DECCHPOSEB 

-patterns->  Batches  vectors  whose  eleaents  aatch  - 
patterns-.  It  is  equivalent  to  [-patterns-]. 


4.6. 1.2. 1. 7. 3  String 

<SIBIIG! -DECOMPOSE! 

-patterns- >  Batches  strings  whose  substrings  aatch 

patterns-. 

<prog  [first  rest] 

<_ 

<string  IjEirst  *  "  !_rest> 
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"see  the  boy"» 
first  gets  the  value  "see* 
rest  gets  the  value  "the  boy" 

<prog  £  root] 

<_  vstrisg  !_root  "s">  *cats">> 
root  gets  the  value  "cat" 


4.6. 1.2.  1. 1.  4  Graph 

<«ODB!-BECOPGSIB 

-properties- >  is  equivalent  to  <AI1  !=BODB  <B1S  - 


proper  ties -». 


4.6. 1.2.1. 2  Aton 


<ATOfl! -DECOBPOSEH 

|s(  |0l>  vill  match  an  a ton  whose  print  naae  is  the 
string  Js]  and  which  is  on  the  oblist  naaed  |o|. 

4.6. 1.2. 1.3  Bord  and  Buaber  Actors 


<10BBBB  >  matches  an  object  only  if  the  object  is  a  nunber. 
Por  exaaple  <nunber>  Batches  3. 

<1ESS 

lap  Batches  any  nunber  less  than  the  value  of  |n|. 

<LBSS* 


lap  Batches  a&y  nuaber  less  than  or  equal  to  the 

value  of  Jn|. 


<GB11TZB 
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| n I >  aatches  any  nuaber  greater  than  the  value  of  |n|. 
<GBEATEB= 

| n ) >  Batches  any  nuaber  greater  than  or  equal  to  the 

value  of  |n|. 

<FIELDS 

-specif ications->  Batches  any  fixed  point  nuaber  which 
Beet  each  specification  of  a  field  in  turn.  A  fixed  pcint  nuaber  x 
aeets  a  specification  cf  the  fora  [|bits]  {pattern]]  only  if  the 
nuaber  which  is  the  byte  of  x  defined  by  I  bits]  Batches  Ipatternl. 

The  expression  <bits  Jsf  | p ] >  deliu^c  a  byte  |s]  bits  wide  which  is 
|p|  bits  froa  the  right  end  of  the  word. 

<fields  [<bits  3  0>  4 ]  [<bits  1  35 >  i  ]>  aatches  a 
fixed  point  nuaber  whose  lower  3  bits  are  4  and  whose  sign  bit  is  on. 

4.6. 1.2. 1.4  Algebraic  Actors 

The  aotivaticn  for  providing  algebraic  actors  is  to  enable 
pattern  directed  algebraic  siaplif ication  to  be  easily  accoaplished. 
Often  it  is  not  clear  which  siaplif ied  fern  is  aost  useful.  Using  the 
hierarchical  backtrack  control  structure  of  FLAIHEfi  one  fora  can  be 
tried  as  a  hypothesis  and  then  in  the  light  of  this  experience  perhaps 
another  sore  suitable  one. 

<!  ♦ 

-patterns-  |rest-of-saaaands] >  aatches  a  sub  such  that 
each  pattern  aatches  a  suaaand  and  the  rest  of  the  suaaands  natch  the 
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pattern  Jrest-of -sunaands j . 


<is? 

<!♦  a  b  <?» 

'<♦  c  fc  a>>  is  true. 

<prog  [y  2  s'] 

<is? 

<!♦  <all  <non  c>  z>  _y  x> 
»<♦  c  b  a»> 

2  gets  the  value  b 
y  gets  the  value  c 
x  gets  the  value  a 

<prog  [y  x] 

<is? 

<1  *  _y  b  x> 

•<♦  1  c  b~d»> 
y  gets  the  value  1 
x  gets  the  value  <+  d  c> 


<SUH-OF 

t 

Jpatl  |  ter»s-that- *atch- pat  1  |rest-of-su»«ands J> 
Batches  any  sue  such  that  the  sub  of  the  sunaands  that  Batch  |pat|  in 
turn  Batch  the  pattern  | terns-that-natch-pat J  and  the  rest  of  the 
sunaands  Batch  the  pattern  { rest-of-sunaands 1 . 


<prog  [y] 

<is? 

<sun-of  <1*  x  <?»  y  <?» 

'<♦  <*  3  x>  <*  y  a>>» 
y  gets  the  value  <♦  <*  3  x» 

<1* 

-patterns-  J rest-of-f actors | >  Batches  a  product  of 
factors  such  that  each  pattern  Batches  a  factor  in  the  product  and  the 
rest  of  the  factors  natch  the  pattern  | rest-of-f actors J . 


<is?  <!*  5  b  c>  *<*  c  b  5»  is  true 
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<pcog  [x  y  ] 

<is? 

<!*  <all  <nuaber>  x>  y  <?» 
«<*  <♦  2  a>  3  a»>” 
x  gets  the  value  3 
y  gets  the  value  <♦  2  a> 

<prog  [x] 

<is?  <!*  3  _x  1>  0» 

x  gets  the  value  0 


<PHODUCT-OF 

IpatJ  jfactors-t hat- natch- pat |  | rest- of-f actors |> 
aatches  any  product  of  factors  such  that  the  product  of  the  factors 
that  Batch  pat  in  turn  natch  |factors-that-natch-pat|  and  the  rest  of 
the  factors  natch  the  pattern  ire.  --of-f actors  1 . 


<prog  [x  y] 

<is? 

<product-of  <non  <nuaber»  x  „y> 
!»<*  a  3  b  5.0»> 
x  gets  the  value  <♦  a  b> 
y  gets  the  value  <*  3  5.0> 

<PO!EH 

|base|  1  exponent | >  Batches  an  exponential. 


<prog  [x  y] 

<is?  <pover  _x  _j>  *<expt  y  2»> 
x  gets  the  value  y 
y  gets  the  value  2 

<prog  [x  yl 

<ls?  <pover  _y>  0» 
x  gets  the  value  0 


<B STB ACT 

| pat |  | terns- vit h-pat-extr acted!  |rest-of-terns|> 
Batches  a  sun  of  terns  such  that  the  sus  of  the  terns  vhich  contain  a 
factor  vhich  Batches  |pat)  Batches  Items- vith-pat-extracted|  and  the 
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saa  of  the  rest  of  the  terms  matches  the  pattern  |  rest- of- tens |  •  The 
actor  EXTBACT  is  due  to  B.  Bledsoe. 

<is? 

<eztract  x  <1+  3  a  0>  y> 

!*<♦  !*<*  a  x>  y  ! '<♦  x  3»>  is  true 

Joel  Hoses  invented  the  example  of  defining  a  quadratic  in  x 
using  patterns. 


<define  quadratic 
<actor 

[x  a  b  c] 

<extract 

<pover  . x  2> 

<all  <non  0>  <non  <con tains  .  x»  <.a»> 
<extract 

.x 

<all  <non  <contains  .x»  <.b>» 
<all  <non  <coctains  .x»  <.c»» 


Thus  if 


<prog  {["special"  al  bl  cl]] 

<is? 

<qaadratic 

y 

<actor  [ ]  _a1> 
<actor  [ ]  _b1> 
<actor  [  j  c1» 

<!♦ 


<1*  3  y> 

<!*  x  *<expt  y  2>  4> 
<!*  c  y»» 


then 

al  gets  the  value  <♦  x  »> 
bl  gets  the  value  <♦  3  c> 
cl  gets  the  value  a 


9.$.  1.2.  1.5  Locative 
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4.6. 1. 2. 2  Type 

COF-TYPE 

)atoa(>  Batches  an  object  (oj  only  if  <-~l  <TTPB  | o| > 
(aton]>  i.e.  only  if  | o }  is  of  the  type  |atoE|.  The  expression  COF- 
TYPE  |atoB|>  aay  be  abbreviated  as  ?  Matca|. 

<&S 

IpatJ  (inj(>  Hatches  an  object  x  only  if  x  is  of  the 
type  of  the  range  of  the  injection  (inj)  and  CRETE ACT  x>  Batches  the 
pattern  (pat(. 

4.6, 1. 3  Identifier 

CGIVEH 

Jtheta|  -bindings->  acts  like  CTALUE  (thetaj  - 
bindings->  if  the  identifier  J theta*  has  a  value.  Otherwise  CGIVBH 
J theta |  -bindings->  Batches  an  object  x  only  if  the  identifier  (theta) 
Batches  x. 

?|theta]  is  an  abbreviation  for  CGIVEI  |theta|> 

!? (theta |  is  an  abbreviation  for  (GIVES  (theta]} 

Ci LTBB (-PERSIST EHT 

(theta)  -bindings- >  Batches  any  expression  x  which 
Batches  the  identifier  | theta]  and  gives  (theta)  the  value  x. 

: ftheta]  4  -  an  abbreviation  for  CALTIB  (theta  I > 


>s 
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!:|theta|  is  an  abbreviation  for  {ALTEB  ) theta)} 


<ALTEB!-?£!!TATI¥E 


(theta |  -bindings- >  Hatches  any  expression  x  which  can 
natch  the  identifier  j theta).  The  identifier  J theta]  is  given  the 
value  x*  However,  if  a  failure  backtrac  s  to  ALTEB t-TEHTATIYE,  then 
{theta)  is  restored  to  its  previous  value. 

_) theta)  is  an  abbreviation  for  <ALTEBI-TERTATI¥E 


{theta j> 


)  theta]} 


theta)  is  an  abbreviation  for  {ALTEB 1-TEKTATIfE 


4.6.2  Exanples  of  the  Cse  of  Actors 


The  rest  of  our  exanples  of  the  use  of  actors  cone  fron  giving 
a  rigorous  definition  of  the  syntax  of  LISP  in  HATCHLESS.  Those 
readers  whc  are  not  interested  in  the  details  of  the  syntax  of  LISP 
should  not  read  section  4.6.2  The  following  grannnar  accounts  for 
essentially  all  the  context  dependent  features  of  the  LISP  syntax.  It 
specifies  that  a  function  call  nust  have  the  right  nunber  of 
argunents.  An  explicit  go  Bust  have  a  tag  to  which  it  can  go.  The 
syntax  specifics  that  sons  identifiers  ar«  free  and  others  are  bound. 

<defiae  top-functicn  <actor  [  ] 
declaration 

(("special"  (tags  (}  J  [ bound vars  ()  ]]] 

(function  <varlist>  <forn>)>» 
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Thus  for  example  Ctop-f  unction>  matches  (function  ()  ())•  The  actor 
top-fonction  introduces  the  pattern  identifiers  tags  and  boandxars  and 
binds  then  to  -  -  which  is  the  null  segaent. 

< define  varlist  <actor  [  1 
<star 

<declaration 

[[ l^atoa  curvar  ]  ] 

_cur»ar 

<be  <is?  _boundwars  {.currar  !  .boundvars) »»» 

The  actor  xarlist  checks  each  identifier  in  turn  to  make  sore  that  it 
is  an  atom  ind  then  puts  the  identifier  in  boundavars. 


Cdefine 

fora  <actor  [ ] 

<vhen 

[<aonadic> 

<either  <coastant>  <war»] 

C 

(!«atoa  {?}} 

Cubes 

I  (P*og  (?} ) 

<progfora>] 
t  (cond  (?}) 

<condfora> ] 

(  (setg  (?) ) 

(<?>  <var>  <fora>)  ] 

[(go  (?}) 

<goforn> ] 

C  (Chas  [subr  <?>]>  {?}) 
(<?>  (star  <fora>} )  ] 
[  (Chas  [expr  <?>]>  (?}) 
Cexprfora>] 

(  (<has  ( fexpr  <?>]>  (?)> 
C?>] 

[{Chas  [fsabr  <?>]>  (?}) 
C?>  j 

[  (Chas  [Isubr  C?>]>  [?}) 
(C?>  (star  \fora>})] 
[ (Chas  [ lexpr  <?>]>  (?}) 
(C?>  (star  Cfora>}  )  1 

(C?> 

Caatcaing 


[expr  '•■optional*  ] 
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<print  („expr  undefined)  »]>  ] 

[((function  {?})  (?) ) 

<f unction-function> ] 

[<?> 

(<fora>  (star  <for»>})  ]>>> 

The  above  definition  s«y s  that  if  a  fora  is  a  aonad  then  it  aust  be  a 
constant  or  an  identifier;  if  its  first  eleaent  is  an  atox  then  if  it 
begins  v it h  the  atoa  prog,  then  it  aust  be  a  progfora  etc.;  if  it 
begins  with  "((function  ..)  ..  )"  then  it  aust  be  a  function-function; 
otherwise  it  aust  be  a  fora  followed  by  a  foralist. 


<define  constant  <actor  [  ]  <either  t  ()  <nnaber»» 


The  only  constants  are  t,  () ,  and  nuabers. 


<define  va^  <actor  J=atoa  [ ] 

<either 

<eleaent  . boundvars> 

<unbonnd»» 

An  identifier  is  either  in  boundvars  or  it  is  unbound. 


<define  condfora  <actor  []  (cond  (dagger  ((star  <fora>))})» 
<define 

progfora  <actor  [  ] 

<declaration 

[ 

[ "special" 

[tags  .tags] 

[local tags  ()  ] 

[boundvars  . boundvars] ] ] 

(prog 

<varlist> 

(all 

<collect-tags> 

<be  <is?  .tags  (!. local tags  I. tags) » 

<star  <either  t*atoa  <fora»>})»> 
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Gn  entrance  to  progforn  tags  and  boundvars  are  rebound  to  their 
previous  values.  The  prog  identifiers  of  the  prog  are  put  in 
boundvars,  the  tags  in  the  prog  are  put  in  tags  by  collect-tags,  and 
the  body  of  the  prog  is  checked  to  see  if  it  is  well  forced. 

<def ine 

collect-tags  Cactor  [  ] 

<star 

<either 

declaration  [ 

[ ! =atoa  curtag  ] 

[‘’special”  localtags]] 

_curtag 
<be  <is? 

_localtags 

{.curtag  !. localtags) » 

<vhen  [<eleaent  ,localtags> 

Cerror  "multiple  defined  tag">] 

<?>»»» 

<def ine 

exprform  <actor  [  ] 
declaration 

[args  functicnvar] 

( 

<has  [expr  (function  _functionvar  {?})]> 

(all  <star  <fora»  _argsj) 

<be  <==?  <length  .  f  unctionvar>  <lenglh  .args»»» 


An  expcf or"!  is  a  call  to  an  expr  with  the  correct  number  of  arguments. 
Hote  that  iaaediately  inside  the  actor  exprfora  the  identifierss  args 
and  functionvar  are  rebound  but  reaain  unassiguad. 


define  gofora  <actcr  [  1 
(go 

<vben 

[ !*atoa 

dither 

<eleaent  . tags> 

<print  (.curtag  undefined  tag)»l 

[<form>]>)  >> 
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&  gofora  is  either  an  explicit  call  to  go  to  a  tag  which  must  be  in 
.tags  or  a  computed  go. 


<define 

function-function  <actor  [  ] 

<declacat ion 

[args  functicnvar] 

( 

<declaration 

C 

["special"  [boundvars  (.boundvars) ]J] 
(function 

<all  <varlist>  _f unctionvar> 

<fora>) > 

(all  <star  <fora»  _args}) 

<be  <==?  <length  .functicnvat  ,args»»» 

In  a  function-function  the  bound  identifiers  of  the  function  must  be 
added  to  boundvars  and  the  function-function  must  have  the  proper 
number  of  arguments. 

The  above  syntax  could  easily  be  extended  in  several 


directions.  For  example  we  c?mld  easily  modify  it  so  that  it  would 
accept  type  declarations  and  do  type  checking.  The  syntax  of 
HATCHLESS  could  easily  be  defined  in  BATCHLESS. 
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4.7  HOBBLE 


Section  4.7  is  logically  completely  separate  froa  the  rest  of 
this  report.  It  is  not  necessary  to  read  this  section  to  understand 
the  rest,  of  the  docuient. 

Be  are  interested  in  exploring  good  ways  to  iapleaent  systens 
like  PLAHHEB  on  aachines.  One  way  is  to  eabed  the  system  in  a 
language  like  LISP  or  PL-1.  The  problem  with  eabedding  is  that  the 
host  language  has  its  cwn  conventions  for  calling  seguences  and  saving 
teaporaries.  The  conventions  light  not  be  ccapatible  with  the  systea 
which. is  being  iapleaented.  Another  approach  is  to  try  to  develop  a 
foraalisa  which  is  sufficiently  flexible  so  that  it  can  adapt  to  the 
higher  level  systew  conventions  but  still  is  efficient  enough  so  that 
it  is  feasible  to  use  as  an  iaplaaentation  language.  The  applicative 
sublanguage  of  H&TCHLES5  see is  to  be  at  approxiaately  the  right  level 
with  the  restriction  that  the  data  are  no  longer  have  types  associated 
with  thea  at  run  tine.  Thus  all  the  type  inforaation  aust  be  able  to 
be  processed  at  coapile  tiae.  The  general  type  definition  foraalisa 
retains  although  the  definitions  aust  be  processed  at  coapile  tiae. 
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4.8  The  Editor 

<EDIT 

jx|>  enables  editing  the  structure  lz]c  The  editor 
naintains  a  special  identifier  CUBS0B1-BDIT  which  represents  the 
position  of  the  editor  within  the  structure.  4  coiaand  way  be 
abbreviated  by  the  first  letter  in  its  name.  The  editor  aakes  use  of 
the  tentative  versions  of  the  structure  modifying  coaaands  so  that  the 
results  of  a  series  of  edits  can  be  undone  by  backtracking.  Gregory 
Phister  made  suggestions  and  iapleaented  an  editor. 

<BEHEATtf  | cursor | >  is  the  expression  beneath  |cursor|  or  <>  if 
there  is  none. 

<COHTAIWS.  (cursor  |>  .is.. the  structure  which  contains  (cursor | 
or  is  <>  if  there  is  none. 

<ABC  | cursor  I ^  is  the  indicator  under  which  <BEMBATu  | cursor) ^ 
is  fcund  under  <COHTAIES  | cursor J>  or  is  <>  if  <COITAIHS  (cursor |>  is 
<>.  That  is  if  <CQITAXBS  (cursor |>  is  not  <>  then: 

<get 

<contains  )cursor|> 

<arc  (cursor I >>  is  <beneath  | cursor 1> 

<GO  |n]  (cursor J>  aoves  (cursor!  (n|  positions  to  the  right  if 
|n|  is  positive  and  jnj  positions  to  the  left  if  |n|  is  negative. 

<BALK  |n]  (cursor J>  walks  |cursor|  (n|  positions  around  the 

tree. 

<0P  |n |  |cursor|>  rises  through  |n|  levels  of  structure  froa 
|  cursor  | . 


<DOiV  1 n |  | cursor (>  descends  through  |n]  levels  of  structure 
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froi  JcursorJ.  If  JnJ  is  positive  the  cursor  is  loved  down  to  the 
right  otherwise  to  the  left. 

<SEARCH  Ipattern)  JnJ  JcursorJ>  searches  for  the  jnjth 
occurence  of  an  object  that  watches  J patternl.  If  jnj  is  positive  the 
search  is  to  the  right,  otherwise  to  the  left. 

<FIHD  jpattern]  Jn]  ]cursor|>  will  conduct  the  search  only  in 
the  object  under  |curscrj. 

<REPLACE  ipattern)  Jx]  ] n J  J cursor 1>  replaces  |nj  occurences 
of  objects  that  Batch  Ipattern]  with  the  valne  of  ]z|.  If  ]n]  is 
positive  the  search  is  to  the  right,  otherwise  to  the  left. 

<CHAHGB  ipatternj  jx]  |n)  |cut£jrJ>  changes  |n|  occurences  of 
objects  that  Batch  ipattern)  with  the  value  of  ]z|  on  the  structure 
which  is  under  Jcursorl. 

CIISEH?  -expressions-  ]cursor|>  inserts  -expressions-  into  the 
structure. 

<KILL  ] n J  jcursorl >  deletes  the  expression  under  the  cursor 
and  <-  1 n |  1>  expressions  following  it. 
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5.  FLAHNE8 


The  PLAHHE8  fonalisi  incorporates  a  unified  set  of  problem 

solving  primitives  that  run  under  a  aultiprocess  backtrack  control 

structure.  The  formalism  itself  is  independent  of  an;  particular 

problem  solving  domain.  The  primitives  of  the  formalism  nake  default 

decisions  in  the  course  of  a  computation  in  those  cases  where  the 

information  supplied  does  not  specify  exactly  what  is  to  be  done. 

However,  as  a  matter  of  principle  each  primitive  allows  a  continuum  of 

expression  from  no  preference  at  all  down  to  the  specification  of 

exactly  one  choice.  The  formalism  is  intended  to  be  used  as  a  matrix 

*>  *  •  - 

in  which  the  necessary  domain  dependent  knowledge  can  be  embedded. 

Bany  of  the  primitives  rely  or  side  effects  to  accomplish  their 
purpose.  Although  the  use  of  side  effects  is  in  opposition  to  some 
theories  of  good  language  design,  their  use  in  PLABBEB  has  worked  out 
well.  The  formalism  encourages  modular  prograr/ming  through  the  use 
of  specialized  routines  to  satisfy  goals  and  make  deductions. 

The  name  PLAHHEB  comes  from  the  desire  to  create  a  formalism 
in  which  it  is  easy  to  express  plans  of  action.  To  construct  a  plan 
in  the  formalism  is  the  same  as  constructing  a  PLABBEB  theorem. 

Bixing  planning  and  deduction  is  guite  easy.  Conditional  plans  are 
explicitly  provided  for  as  is  the  ability  to  backtrack  in  case  of 
failure. 

Consider  a  statement  that  matches  the  pattern  (IHPUES  ItJ 
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|y]].  The  statement  has  several  imperative  uses. 

stl:  If  ve  can  deduce  |x],  then  ve  can  deduce  ]y]. 

In  PLAHHEB  the  stateeent  stl  would  be  expressed  as  <AHTECEDEMT  []  |x] 
<AS5EBT  jyj>>  which  Means  that  |x]  is  declared  to  he  the  antecedent  of 
a  theorea  such  that  if  ]x{  is  ever  asserted  in  such  a  way  as  to  allow 
the  theorea  to  becoae  activated  then  |y]  is  asserted. 

st 2:  if  ve  want  to  deduce  ]y|» 

then  establish  a  subgoal  to  first  deduce  i x | • 

In  PLAHHEB  the  stateaent  st2  would  be  expressed  as 

<COHSBQUE»T  [ ]  Iy| 

•  <G0IL  | X i >  . 

<ASSIBT  Iy|» 

which  aeans  that  |y|  is  declared  to  be  the  consequent  of  a  theorea 
such  that  if  the  subgoal  ]x|  can  be  established  using  any  theorea  then 
the  consequent  ]y|  is  asserted. 

He  could  also  assert  <CLAUS2  []  [HOT  lx]]  ]y|>  which  is  a 
clause  which  says  that  [not  |x]  ]  or  |y|  is  the  case.  P1AHIES  has  goal 
oriented  priaitives  xor  using  and  Manipulating  all  of  the  above 
variants.  For  certain  purposes  any  one  of  the  variants  can  be  sore 
useful  than  the  others.  Inperativa  inforaation  and  hanristics  can 
aore  easily  he  expressed  in  the  procedwral  variants.  For  exanple 
heuristic  inforaation  as  to  whan  ve  skonld  create  a  subgoal  x  ia  order 
to  achieve  y  can  aore  eaaily  be  incorporated  into  a  CGRSEQOBHT 
theorea.  [On  the  other  hand  ve  caa  aore. eaaily  deduce  <gLjJ3SB  [  J~c 
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d>  froi  CCLAUSE  [}  x  £  SOT  y]  c  d>]  Of  coarse  the  distinction  is  not 
sharp  since  the  tvo  kinds  of  assertions  can  be  combined  by  aaking 
assertions  about  the  actions  of  iapecatives. 


5. 1  page  203 


5. 1  PLAUREB  Foras 


5.1.1  Hierarchical  Backtrack  control  Structure 

PLANNEB  uses  a  control  structure  in  which  the  hierarchy  of 
calls  is  preserved  so  that  a  coaputaticn  can  backtrack  to  an 
activation  froa  which  it  has  already  returned.  Backtracking  preserves 
the  nesting  of  block  structure.  It  siaply  traverses  the  stateaents 
executed  in  reverse  order.  The  primitive  functions  PAIL  and  F1ILPOINT 
enable  the  backtrack  process  to  be  controlled.  The  fora  <FAIL> 
generates  a  siaple  failure  which  backtracks  to  the  aost  recently 
executed  fora 

<FAILP0IHT  ♦activation-naae*  [-declarations-] 

J expression | 

[laessagej  | activation |  ] 

-body-> 

Where  laessagej  is  bound  to  the  aessage  of  the  failure  and  the 
predicates  are  evaluated  to  try  to  find  one  which  is  true.  For 
example 


<Ptog  [[x  3]] 


<prog  foo  [  ] 

<failpoint  [  ] 

.x 

[-."optional"  ] 

<.foo  <_  : x  4>> 

;"exit  .foo  with  4"» 
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;**tbe  first  ti*e  through  the  above  expression 
has  .x  as  its  value** 

<cond 

[ <is?  3  . x> 

<fail>] 

[-•"else** 

5  ]»> 

evaluates  to  <♦  4  5>  which  is  9. 

The  identifier  x  is  declared  to  be  a  fixed  point  integer  which  is 
initialized  to  3.  The  value  of  <£ailpoint  [  ]  .x  [-•’’optional**]  <_  :x 
4»  is  3.  Hhen  the  second  arguaeni  of  the  call  to  is  evaluted  the 
conditional  detects  that  x  is  bound  to  3  and  so  generates  a  staple 
failure.  The  failure  backtracks  to  the  call  to  PAILP0X1T  with  the 
■essage  <>  which  is  PALSE.  the  identifier  x  is  assigned  the  value  4 
and  the  rest  of  the  computation  proceeds  noraally. 

Th'e‘top  level  function  of  FLASHES  is  a  read,  evaluate,  prxnt 
loop.  Hhen  the  expression  read  is  successfully  evaluated  then  the 
whole  hierarchy  of  calls  is  forgotten,  the  value  is  printed,  and  the 
process  repeats. 

One  of  the  aost  straight  forward  ways  to  lapleaent 
hierarchical  backtrack  control  structure  is  through  the  use  of  a 
backtrack  stack  on  which  backtrack  inforaation  is  stored.  Th*;  only 
tricky  point  coaes  in  the  exdcuton  of  an  exit  where  the  temporaries 
last  be  pushed  onto  the  backtrack  stack  before  doing  the  exit.  The 
other  straight  forward  aethod  of  inpleaentation  is  not  to  have  a  stack 
at  all  but  rather  to  keep  all  the  activation  fraaes  in  garbage 
collected  storage.  The  stack  iapleaentation  has  the  advantages  that 
it  keeps  a  smaller  working  set  and  doesn’t  cause  garbage  collection. 
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The  sva&p  iaplenentation  has  the  advantages  that  it  is  conceptually 
cleaner  and  is  aore  flexible.  The  ideal  iapleaentation  is  to  be  able 
to  run  either  node.  In  stack  node  the  acivation  records  are  siaply 
tuples  on  the  stack. 

The  use  of  backtrack  control  structure  has  the  iaportant 
fringe  benefit  that  it  allows  us  to  debug  aore  easily.  le  have 
available  the  following  control  praitives. 

<STEP  |p|  ]n l  |condition|>  executes  the  process  «p|  for  ]n| 
eleaentary  steps  unless  the  | condition)  is  aet  in  which  case  it 
returns  the  nuaber  of  eleaentary  steps  completed.  If  ln|  is  negative 
then  the  process  is  executed  8ACSH1BDS1  This  enables  us  to  zero  in  on 
bugs  by  running  forwards  and  backwards  until  the  bug  is  found. 

<INVGKE  )pj  |ni  )condition|>  executes 'the  process  |p|  for  )nl 
procedure  invocations  unless  the  JconditionJ  is  net  in  which  case  it 
stops  and  returns  the  nuaber  of  procedural  invocations  which  have  been 
completed.  Again  if  )n|  is  negative  then  the  process  is  run 
backwards. 

5.  1.2  PLANNEE  Functional  Foras 

The  functional  foras  in  PLANNEE  are  FOHCTICN  and  ACTOB.  The 
sole  change  in  the  semantics  is  that  the  functional  foras  of  PLANNEE 
can  handle  pattern  directed  invocations. 

The  following  exaaple  illustrates  the  syntax  of  functional 
foras.  The  function  lflONG  which  is  defined  below  is  a  generally 
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useful  PLANNEB  function.  What  AMONG  does  is  to  successively  return 

the  elements  of  the  structure  given  as  its  argument.  For  example 
<among  [E  A  ]>  returns  E  as  its  value.  But  if  a  simple  failure 

backtracks  to  it  then  it  returns  A  as  its  value  and  continues  the 

computation.  But  if  still  another  siaple  failure  backtracks  then  it 
allows  the  failure  to  continue  to  propagate  through  the  function 
AMONG.  The  particular  way  in  which  the  function  AMONG  is  used  here 
does  not  accomplish  anything  that  cannot  be  done  easily  in  LISP.  We 
give  this  example  because  it  is  simple  enough  to  be  easily  understood. 
One  way  to  assign  to  the  identifier  x  the  value  which  is  the  first 

element  of  .list  that  is  greater  than  5  would  be 

<is 

({?}  „<all  Xgreater  5>  :x>  {?} ) 

.list> 

Another  way  would  be  <is  _x  <larger  5  <among  .list»>  where 


<define  amopg  Cfuncticn  munqer  [list]  <prog  [first] 
Cfailpoint  forward  f  ] 


if 


O 

^establish  a  failpoiat  and  return  <>" 

£■  a?] 

;"on  backtracking  let  a  be  the  message  and  a?  be  true 
the  failure  will  propagate  through1* 

Ccond 


[  <not?  <is?  .n  <>» 

; •"if  the  message  is  not  <> 

then  restart  the  failure"] 

[ <is?  .a  <» 

;"the  message  is  <>" 

<restore  . fcrward> 

;"start  going  forward  agai 

with  the  failpoint  restored"  ]» 


<cond 

[<eapty?  .list> 
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;"if  list  is  eapty  generate  a 

siaple  failure  out  of  aaong” 

<fail  <>  . aunaer>] 

[-"else” 

<_  <linear  : first  !:iist>  . list> 

;"set  first  to  the  first  of  .list  and 
list  to  the  rest  of  .list” 

<.munger  .first> 

;"exit  *.  aunger  with  .first”]»» 

<define  larger  <f unction  [a  bj 
<cond 

[<is?  <grea^er  .b>  .a> 

;"if  a  is  greater  than  b  then  return  a" 

.a] 

[-"else” 

; "otherwise  generate  a  failure  with  the  aessage  <>" 
<fail  0>]»> 


Thus  the  value  of  <larger  <aaong  (2  4  6)>  5>  is  6. 


5.  1c  3  PLANNEE  Theoreas 

PLANNEE  allows  procedures  to  be  invoked  by  a  pattern  which 
states  what  tbe  procedure  is  supposed  to  accomplish. 

There  are  four  kinds  of  theoreas  which  are  presently  defined 
in  the  language  for  satisfying  requests  nade  in  the  body  of 
procedures: 


1.  Consequent  theoreas  for  satisfying  goals.  Consequent 
theoreas  are  the  aost  fundaaental  in  the  sense  that  they  can  easily  be 
used  to  siaulate  the  other  two  kinds  of  theoreas. 

2.  Antecedent  theorems  for  deducing  the  conclusions  of 


PATTERN  DIRECTED  INVOCATION 
DATA  BASE  OPERATIONS 


NOTE  :  IN  ALL  CASES  PAT  1  MUST  MATCH  PAT  2  IN  ORDER 
FOR  THE  INVOCATION  TO  BE  SUCCESSFULL. 
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assertions 

3.  erasing  theoreas  for  deducing  conclusions  fron  the  fact 
that  sone  assertion  is  no  longer  true 

U.  Siaplifying  theoreas  are  for  siaplyfying  expressions. 


5. 1.3.1  Conseguent 

<CCHSEG0ENT 

-type-  ♦activation-naae* 

{declaration-specification | 

{conseguent- pattern! 

-body-> 

evaluates  to  a  procedure  which  declares  that  {conseguent-patternl  is 

the  conseguent  of  a  theorea  which  can  be  used  to  try  to  establish 

•  •• *  *  * 

goals  that  natch  the  pattern  (conseguent-patternl.  Whether  or  not  the 
theorea  actually  succeeds  in  establishing  the  goal  depends  on  the 
body.  Typically  the  first  action  that  a  theorea  of  type  conseguent 
takes  is  to  try  to  reject  the  goal.  Re  cannot  eaphasize  too  strongly 
the  iaportance  of  analyzing  the  conseguences  of  goals  in  order  to 
reject  the  ones  which  cannot  be  achieved.  Even  if  no  absurdity  is 
detected,  the  consequences  are  often  just  the  stateaents  that  are 
needed  to  establish  the  goal.  The  only  way  that  a  theorea  that  begins 
with  the  atoa  conseguent  can  be  called  is  by  the  pattern  directed 
call: 


<CALL 

[ <[GOAL  1  goal-pattern)  ]> 
frecoaaendation ] 
| state -path |  ]> 
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which  attempts  to  satisfy  the  goal  J goal-pattern  1  where  Icortsequeat— 
pattern j  Batches  j goal- pattern j  and  the  consequent  theoren  is  in  the 
data  base  specified  by  Jstate-path J,  The  function  COHSEQUBNT  is 
defined  to  be: 

<FONCTIOH  +checker+  ♦activation- name+ 

[-•"PATTEBN" 

[ ] declarations )  [GOAL  j consequent-pattern ] j ] ] 

-body-> 

The  following  theorei  says  that  if  it  is  our  goal  to  prove  x  and  we 
have  proved  that  w  iiplies  x  then  we  should  Bake  it  cur  goal  to  prove 
v. 


Consequent  [x  w]  ?x 

Current  [inplies  ?v  ?x]> 
<goal  „w>> 


The  following  theorem  says  that  two  things  ate  equal  if  they  are 
identical. 


Consequent  [x]  [=  ?x  ?x  ]> 


With  this  consequent  theorea,  evaluating  the  following  causes: 
<prog  [a] 

;"declare  an  identifier  a" 

<goal  [=  ?a  3 

;"a  gets  the  value  3  since  a  is  linked  to  the 

identifier  x  in  the  consequent  theorea"> 

<prog  [a  cl 

;"aeclare  a  and  c" 

<prog  Cf.J 

; "declare  b" 

<goal  [*  ?a  ?b  ]> 
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;"a  is  linked  to  b" 

<goal  [*  ?b  ?c]> 

;"b  is  linked  to  c"> 

<goal  [=  ?1  3  ]> 

;"a  gets  the  value  3  and  so 

therefore  c  gets  the  value  3"> 


5.  1.3.2  Antecedent 


<ABTICED£HT 

♦checker* 

] declaration-specification J 
| antecedent- pattern | 

-body-> 

evaluates  to  a  theorea  which  declares  that  |antecedent-pattern|  is  the 
antecedent  of  a  theorea  froa  which  conclusions  nay  be  drawn  by  the 
body.  Th',  theorea  can  be  used  to  try  to  deduce  consequences  froa  the 
fact  that  a  stateaest  that  Batches  the  antecedent  has  been  asserted. 
The  only  way  that  a  theorea  that  begins  with  the  atoa  antecedent  can 
be  called  is  by  the  pattern  directed  call: 


<CALL 

£<[ ASSIST  Jassert-pattern]  ]> 

! recommendation j 
Jstatc-patbJ  ]> 

which  draws  conclusions  frca  (assert-pattorn J  where  Jassert-pattecnl 
Batches  .  (antecedent- pattern |  the  anteccdndent  theorea  statistics 
I recoanendation J  and  the  antecedent  theoren  is  in  the  data  base 
specified  by  | state- path] .  The  function  AITECEDEM?  is  defined  to  be: 


<pa*CTI0»  ♦checker*  ♦activati?a-nane* 

[-.«PATTSHI« 

[ | declarations!  [ASSIST  | antecedent- 


pa  t  tern  |  333 


-body-> 
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The  following  theorea  says  that  if  we  assert  something  of  the  fora 

[not  [ ia plies  Z  T]J  then  we  should  deduce  X. 

Antecedent  [x  y]  [not  [iaplies  _x  _y]]  <assert  .i» 

The  following  theorea  says  that  if  soaething  of  the  fora  [Barry  Jxj 
iyj]  is  asserted  then  [bachelor  IxJ]  should  be  erased. 

Antecedent  [x  y  ] 

[aarry  _x  _y] 

<erase  [bachelor  .x]>> 


5. 1.3.3  Brasing 


<EB1SIIG 

-type- 

J declaration-specification | 

| erasing- pattern | 

-body-> 

can  be  used  to  try  to  deduce  conseguences  froa  the  fact  that  a 
stateaent  that  Batches  the  patt'- ,'n  J erasing-pattern J  has  been  erased. 
The  only  way  that  a  function  of  kind  erasing  can  be  called  is  by  the 
expression 


<CALL 

[<[  ERASE  J erase- pattern ( ]> 

| recouwendation] 

■  .  fstafc^pathj  }> 

which  expresses  the  fac*  that  there  hzj.’  been  a  change  in  the  world 
affecting  (erase  pattern |  where  ( erase-pattern (  Batches  Jercsing- 
patternl.  The  functicn  ER1SI1G  is  defined  to  be: 


<?OHCTIOH  ♦checker*  ♦actiTation-aaae* 

[-."PATTEII" 

[ (declarations!  [ ERASE  (erasing- pattern!  ]]] 
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-body-> 


The  following  theorem  says  that  if  something  of  the  fora  [alive  x]  is 
erased  then  [dead  xj  should  be  asserted. 


<erasing  [x] 

[alive  _x  ] 
<assert[dead  .x]>> 
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5.2  FLASHES  Functions 


5.2.1  Data  Priaitives 

Soae  of  the  functions  in  PLANNEB  are  given  below  together  with 
brief  explanations  of  their  purpose  Examples  of  their  use  are  be  given 
immediately  after  the  definition  of  the  priaitives  below.  The 
priaitives  probably  cannot  be  understood  without  trying  to  understand 
the  examples  since  the  language  is  highly  recursive.  In  general 
PLAHHEB  reaenbers  everything  that  it  is  doing  on  all  levels  unless 
coaaanded  to  forget  some  part  of  this  information.  The  default 
response  of  the  language  when  a  siaple  failure  occurs  is  to  backtrack 
to  the  last  decision  that  it  made  and  to  aake  another  choice. 

<C ABDICATES 

Ikind)  ipatternj  | st ate- path | >  ate  the  ]kind| 
candidates  that  have  the  saae  coordinates  as  J pattern |  and  are  in  the 
local  data  base  defined  by  |state-path  J .  CANDIDATES  is  the  basic 
retrieval  function  for  the  data  base.  The  candidates  can  be  generated 
increaentall}  if  .it  is  not.  desired  to  construct  then  all  at  once  at 
the  beginning.  The  kind  of  data  retrieved  aay  be: 


COBBENT  for  assertions 
FUNCTION  for  functions 
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5. 2. 1.1  Assertions 

<ASSEBT!-TEHTA1I VE 

IstateaentJ  (rec,  [ -i"PATH  J state-path J  ]  [-*"ALBIADT" 
Jalready-current | ]>  puts  (statement]  in  the  data  base  defined  by 
jstate-path|  ard  tries  to  draw  conclusions  according  to  the 
recoaaendation  jrecj.  Eecoaaecdations  are  optional;  the  default 
recoaaendation  is  [-*"TBT"]  which  says  not  to  try  any  theoreas.  If  the 
stateaent  is  already  in  the  data  base  then  Jalready-current |  is 
evaluated.  If  the  value  of  lalready-current]  is  -*HBEASSBHT"  then  the 
jstateaentj  is  asserted  in  the  first  eleaent  of  Jstate-path| .  The 
-•"reassert"  feature  is  due  to  Drew  HcDeraott.  Otherwise,  the  function 
ASSEBT  causes  the  stateaent  stateaent  with  properties  to  be  inserted 
in  The  data  base  which  is  the  first  eleaent  of  (state-path | .  Then 

CCALL 

[<( ASSEBT  (statement ( ]> 

(state-patbj 
(rec( ]> 

is  evaluated  to  draw  conclusions  froa  stateaent.  If  the  call  to  DBAH 
ultimately  fails  then  (stateaent]  is  reaoved  froa  the  data  base.  The 
argument  | already-currentj  is  due  to  Peter  Bishop.  The-  recoaaendation 
is  optional.  The  value  of  the  function  ASSEBT  is  the  arc  froa  the 
state  which  contains  the  assertion  having  as  indicator  the  assertion. 

<assert 

<put 

[subset  t  b] 

[difficulty  trivial ]» 
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asserts  that  tbe  set  a  is  a  subset  of  the  set  b  and  put  the  value 
trivial  under  the  indicator  difficulty. 

<ASSEBT! -PEBSISTBNT 

{statement]  Jrecj  [-"PATH  | state-path |  ]  [-*"ALfi£AET" 
lalready-currentl ]>  is  exactly  like  ASSEBTI-TEMTATIVE  except  that 
jstatenentl  is  not  withdrawn  froa  |state-path|  on  backtracking. 

Expressions  of  the  fora  <C LA DSE  [declarations]  -alternatives-> 
denotes  an  assertion  with  variables  declared  followed  by  logical 
alternatives.  For  exaaple 


<assert 

<claus»:  [[<set>  x  y  2]] 

[not  [subset  ?x  ?y]] 

[not  [subset  ?y  ?z]] 

[subset  ?x  ?z]» 

assarts  in  declarative  fora  that  the  subset  relation  is  transitive  for 
set-=.  In  other  words  it  is  equivalent  to 


<assert 

<ciause  [[<set>  x  y  zj] 

[implies 
[  and 

[subset  ?x  ?y] 

[subset  ?y  ?z]] 

[subset  ?x  ?z]]» 

-Another  kind  of  assertion  is  one  which  has  variaffTes  which  are 
consuaed  by  being  bound  For  exaaple  if  we  translate  the  assertion 
that  John  is  soaevhere  as  <assert  <closure  <clause  []  [at  John  ?x]> 
x»,  then  <goal  [at  John  store  ]>  causes  x  to  be  bound  to  the  atoa 
store.  Thereafter  <goal  [at  John  hoac]>  fails  since  the  identifier  x 
was  consunaed  in  being  bound  to  the  atoa  store.  The  above  problem  was 
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suggested  by  Gene  Charniak. 

9.  Bledsoe  suggested  trying  the  problea  of  showing  that  [all  a 
[soae  b  [p  b  a]]]  follows  froa  [soae  z  [all  y  [p  x  y]]]. 

<assert  <clause  [y]  [p  [zO]  ?y ]» 

<prog  £  b  ] 

<goal  <clause  [ p  ?b  [a0]]>>> 
b  gets  the  value  £x0] 

The  expression  <clause  [y]  [p  [xO]  ?y ]>  is  the  assertion  Skolea  fora 
of  the  assertion  [soae  x  [all  y  [d  x  y]]]  where  xO  if.  the  Skolea 
function  for  x.  The  expressions  <clause  £p  ?b  [a0]]>  is  the  goal 
Skolea  fora  of  [all  a  [soae  b  [p  b  a]]]  where  aO  is  the  Skolea 
function  for  a.  On  the  other  hand  if  we  were  to  try  to  derive  [soae  x 
[all  y  [p  z  y]]]  froa  [all  a  [soae  b  [p  b  a]]]  we  would  fail: 

<assert  <clause  [a]  [p  [  bO  ?a  ]  ?a]» 

<prog  [x] 

<gcal  <clause  [p  ?x  [yO  ?x]]>» 

The  identifier  x  cannot  be  be  bound.  The  aany-sorted  caega  order 
quantificational  calculus  of  PiAHNEB  allows  for  the  possibility  of 
null  doaains.  For  exaaple  it  does  not  follow  that  there  is  a  god 
which  is  a  deity  if  we  assuae  that  all  gods  are  deities.  That  is 
[soae  [in  g  god]  [deity  g]]  does  not  follow  froa  [all  [ in  g  god] 

[deity  g]j.  Thus  we  cannot  prove  the  existence  of  a  god  so  easily. 
However  [soae  [in  g  god]  [deity  g]]  does  follow  froa  [scae  [in  g  god] 
[aythical  g]]  and  [all  [in  g  god]  [iaplies  [aythical  g]  [deity  g]]]. 

<assert  [aythical  [gU]]> 

<assert 

Cclause  [[<god>  g]] 

[not  [aythical  ?g]] 
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[deity  ?g]» 

<pcog  [[ <god>  x]] 

<teraprog  [  ] 

<assert  <clause  []  [not  [deity  ?x]]» 

; "assert  that  there  are  no  gods  which 

hare  the  property  of  being  deities" 
<prog  [ literal  1  literal2] 

<carrent 

<clause 

<all 

[deity  <?>] 

Iiteral2> 

<?>» 

<c urrent 

<clause 

<all 

[not  [deity  <?>]] 
_literal1> 

<box»> 

<assert 

<resolve 

. literal 1 
,literal2>>> 

;"resolTe  a  clause  which  contains  an  elenent 
which  Batches  [deity  <?>]  and 
a  singleton  clause 
whose  elenent  Batches 
[not  [deity  <?>]]  producing 
Cclause  []  [not  [nythical  ?x]]>  which 
is  then  asserted" 

<prog  [literall  literal2] 

<current 

<clause 

<all 

[nythical  <?>] 
_literal1> 

<box»> 

<current 

<clause 

...  .  .  <all 

[not  [nythical  <?>]] 
_literal2> 

<box»> 

<assert 

<resolve 

.literall 

.literal2»> 

resolve  two  singleton  clauses; 
one  containing 

a  positive  instance  of  nythical  and 
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one  a  negative  instance. 

this  binds  z  to  [gO]  and  produce  a 

clause  which  is  written  <box>" 
Ccurrent  <box» 

;wthus  we  have  derived  the  null  clause  which 
is  a  contradiction^ 

<assert  <clause  []  [deity  .x]»> 
j"assett  [deity  [gOJ]" 


5.2. 1.2  Erasures 

<EBASE!-TENTAT1¥E 

jstateaent  j  (reel  [-"PATH"  (state-path j J  [-"HOT-FOUBD" 
jnot-foundl J>  tries  to  rind  an  assertion  |a]  in  |state-path(  in  the 
data  base  that  latches  (statement}.  If  such  an  assertion  |a|  is  found 
then  it  is  erased  and 

<CA1L 

[<[  ERASE  J  a|  ]> 

(recommendation] 

J  state-path |  ]> 

is  evaluated  to  assay  the  implications  of  the  change,  if  no  such 
assertion  is  found  then  jnct-found|  is  evaluated.  If  the  change 
statement  fails  or  if  a  failure  backtracks  to  the  function  BBASE,  then 
|a).is  reinserted  in  the  .data  base  and  the  whole  process  repeats  with 
another  statement  from  the  data  base.  The  value  of  the  function  BBASE 
is  an  arc  from  an  element  of  }state-path|  with  indicator  a  statement 
which  matches  (pattern |.  The  reader  should  be  careful  not  to  confuse 
what  happens  vten  the  function  BBASE  is  called  to  remove  something 
from  the  data  base  with  what  happens  when  an  ASSBBTIOH  fails  and  thus 
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reaoves  what  was  asserted  froa  the  data  base.  The  function  EBASE  nay 
atteapt  to  do  pattern  directed  invocation  to  deduce  consequences  of 
the  deletion  whereas  ASSEBT  will  not.  The  arguaent  |not-foundj  is  due 
to  Peter  Bishop. 

<erase  [cn-top-of  brick  1  brick2]>  erases  the  fact  that  brick  1  is  on 
top  of  brick2. 

<EBASE!-PE8SISTEHT 

JstateaentJ  IrecJ  [-."PATH"  Jstate-path]  J  [  3"  H  OT-POD  HD" 
Inot-found J ]>  is  exactly  like  the  function  EBASE l-TSHTATlfB  except 
that  the  assertion  deleted  froa  | state-path J  is  not  re-inserted  on 
backtracking. 

5. 2. 1.3  Goals 

CCOBBEHT? 

| pattern J  J state-path J>  tests  to  see  if  a  stateaent 
that  Batches  j pattern]  currently  is  in  | state-path].  If  there  is  such 
a  stateaent,  then  the  identifiers  in  | pattern]  are  bound  to  the 
appropriate  values.  If  there  is  no  such  stateaent,  then  CD”BEHT? 
returns  false. .  a  staple  failure  backtracks  to  the  function 
CDBBEIT,  then  the  identifiers  that  were  bound  are  onbound.  Then  the 
whole  process  repeats  rith  another  stateaent  in  the  data  base. 

PLAHHEH  is  designed  so  that  the  tine  that  it  takes  to 
determine  whether  a  stateaent  that  Batches  pattern  is  in  the  data  base 
or  not  is  esseatially  independeat  of  the  nuaber  of  irrelevant 
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stateaents  that  have  already  been  asserted.  A  coordinate  of  a 
structure  is  defined  by  sole  atoa,  nuiber,  or  string  being  in  soae 
position  of  the  structure.  Hhen  an  s- expression  is  asserted  PLAHMEB 
reaeabers  every  coordinate  that  occurs  in  the  s~ezpression.  Two 
expressions  are  siailar  on  retrieval  only  to  the  extent  that  they  have 
the  saae  coordinates.  The  function  <HEBGE  ) v |  |1|>  sill  serge  |v| 
into  the  list  |1|.  Consider  the  siaple  assertion 

<assert  .z  [-'"path*1  (.si)  ]>  where  si  is  bound  to  a  state  and  z 
is  bound  to  ~«£a  (b  c]]  causes  the  following  changes: 


<put 


<position  1  current> 
£a 

<aerge 


.2 

<get  a 


<position  1  current> 

(0) 

;"if  the  bucket  is  eapty  then, 
initialize  it  with 
an  eapty  list"»]> 


<put 

<position  1  <position  2  current» 

[b 

<aerge 

o* 

<get  b 

< position 
1 

<pcsition  2  current» 

|0)»]> 


<put 


<position  2  <position  2 

[c 

<aerge 


.z 

<get  c 


current» 


<position 
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2 

<position  2  current» 

{0)»]> 

<put  .si  r.z  -."asserted"  1> 

Classes  are  stored  in  tuckets  under  the  position  -."class".  Thus  the 
assertion  <assert  .w  ["•’’path'1  (.si)  ]>  where  w  is  bound  to  [nonempty 
<class  e  f>]  would  result  in: 


<put 

<position  1  current> 

[nonempty 

<merge 

.« 

<get  nonempty 

<position  1  current> 

(0) 

{••if  the  bucket  is  empty  then, 
initialize  it  with 
an  empty  list"»]> 

<put 

<position  -»"clas s"  <position  2  current» 

[g 

<merge 

-w 

<get  e 

<posation 

-."class" 

<position  2  current» 

10) » )> 

<put 

<position  -."class"  <position  2  current» 

[f 

<merge 

.  .  .  ...  . «»  • 

<get  f 

<position 

-•"class" 

<positicn  2  current» 

(0)»J> 

<put  .si  [  .w  -."asserted" ]> 

Clauses  are  classes  at  their  top  level.  For  example  the  clause 


TREE- STRUCTURED  WORLDS 


ASSERTED 

INITIAL  WORLD  WITH  B  ON  A  WHICH  IS  AT  POSITION  PI 


.  ...  ERASED 

PUSHED  DOWN  WORLD  WHERE  B  HAS  BEEN  MOVED  TO  THE 
LEFT  OF  A.  NOTE  THAT  A  IS  STILL  AT  PI  FROM  THE  POINT 
OF  VIEW  OF  THIS  WORLD,  HOWEVER  B  IS  NO  LONGER  ON  A. 


<clause  []  [not  [on  a  b]]  [on  a  c]>  would  be  stcrad  under  the 
coordinates  for  [not  [  cn  a  bj]  and  [on  a  c],  Variables  in  expressions 
are  ignored  on  indexing.  Thus  two  expressions  which  are  the  saac 
except  for  change  of  variables  are  considered  equivalent.  When  the 
bucket  under  soae  coordinate  exceeds  a  threshold  then  the  bucket  could 
be  sub-divided  by  taking  the  coordinates  by  pairs.  The  only  reason 
that  we  don’t  store  stateaents  under  all  the  possible  ccabinations  of 
coordinates  is  that  we  can  not  afford  to  use  that  auch  space.  Storing 
the  most  recent  assertion  at  the  front  of  a  bucket  also  tends  to  speed 
retrieval.  If  a  total  ordering  is  imposed  cn  the  assertions,  then  the 
buckets  can  be  sorted,  fiichard  Greentlatt  has  constructed  a  clever 
total  ordering  on  the  assertions  which  also  has  the  advantage  of 
storing  new  assertions  at  the  front  of  the  buckets.  The  total 
ordering  is  constructed  incrementally  as  assertions  are  aade.  If 
MATCHLESS  had  an  efficient  parallel  processing  capability  tnen  the 
retrieval  could  be  even  faster  since  we  would  do  the  look-ups  on 
coordinates  in  parallel.  We  aiyht  iaagine  a  aachint  with  aultiple 
prograa  counters  each  c£  which  is  capable  of  interrupting  the 
execution  of  the  others.  However,  with  the  current  technology  it 
appears  wore  econoaical  to  tiaeshare  a  few  very  fast  physical 
processors.  Clauses  are  stored  in  a  special  way  for  efficiency.  The 
value  of  the  expression  <C(JBBENT  ]  pattern  |  |state-pathf>  is  aa  arc 
from  the  state  in  fstate-path|  which  contains  the  assertion  sith 
indicator  naae  being  an  assertion  that  matches  ) pattern!. 
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<current? 

[subset  a  b] 

[-•nuseH  <has  [difficulty  trivial  j>3> 
is  true  only  if  it  has  been  proved  that  a  is  a  subset  of  b  with  the 
value  trivial  under  the  indicator  difficulty.  He  shall  use  the  prefix 
operator  ?x  for  <GJVEK  x>  to  denote  variables  of  the  quantificational 
calculus.  The  concept  of  a  variable  is  different  fro*  that  of  an 
identifier  in  that  variables  have  global  scope. 


given: 


<assext 

<put 

<clause  [[<objecf>  xj  [ <set>  y  z]] 
[subset  [ f  ?x  ]  ?y ] 

[subset  ?y  ?zj> 

[difficulty  hard]>> 

The  above  statement  says  that  for  all  objects  x  and  sets  y  z  that  ££ 
x]  is  a  subset  of  y  cr  y  is  a  subset  of  z.  evaluate: 


evaluates 


<prog  [[<set>  k  u]  ] 

<current 

<clausc  [subset  _w  <?»» 


to  <clause 

[[<object>  x] ] 

[subset  ff  7x3  [f  ?x  3  ]> 

v  gets  the  value  [f  7x3 
u  gets  the  value  [f  7x3 


CCOBBEHT 

{pattern]  ] state-path] >  is  exactly  like  COBBBHT? 
except  that  if  it  runs  out  of  objects  tbct  are  currently  in  Jstate- 
path]  which  watch  { pattern |  then  it  generates  a  siaple  failure  instead 
of  returning  false.  The  value  of  COBBEBT  is  the  node  which  is  the 
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property  list  uf  an  assertion  in  1  state-pa thj  which  Batches  | pattern J 
<GOIlL 

Jgoal-pattern I  IrecJ  £-»"PATHw  Jstate-path|  ]]>  tries  to 
achieve  the  J goal- pattern!  according  to  a  recommendation  )reci. 
Beconaenda tions  are  optional;  the  default  recon.  endation  is  [^"OSE" 
-•"GOSHEHT"  <?>]  which  means  the  data  base  is  searched  to  see  if  there 
is  soaething  already  proved  which  watches  | goal-pattern  1  then  use  it 
otherwise  try  any  consequent  theorea  whose  consequent  watches  |goal- 
pattern|.  The  recoaaendation  Jrec]  nust  be  of  one  of  the  following 
two  foras: 


Is  0**CSE" 

-."CDBBHEIT" 

-pats-]  is  equivalent  to 

<COHD 

[<C0HB2KT?  J goal-pattern |  J state-path I> J 
r-.«BLSB" 

<CALL 

[ <£ GOAL  J goal-pattern |  ]> 

£-.*0SBr  -pato-  ] 

Jstate-pathi ]>]> 

2:  [-»"USB1* 

-."CORSBHT" 

-pats-]  is  equivalent  to 

<COSD 

[<C0BBIBT?  | goal-pattern J  |state-path J>] 

[-."ELSE" 

<CA11 

[ <[GOAL  (goal-pattern J ]> 

£  •'"DSB"  -pats-] 

(state-path J ]> ]> 

The  -»"US11"  recoaaendation  is  due  to  Pat  Kinston*  Alan  Kay  has 
suggested  that  the  syntax  of  PLAKBEB  could  be  easily  changed  so  that 
every  expression  is  a  goal.  Thus  instead  of  writing  <GOAL  x>  we  would 
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simply  write  x.  Alan's  suggestion  has  the  merit  that  it  siaplifies  the 
language.  One  reason  that  we  do  not  do  this  is  that  pattern  directed 
invocations  are  somewhat  aore  inefficient  than  straightforward  calls 
in  which  the  name  of  the  called  function  is  explicit.  Anyone  vho 
prefers  the  other  syntax  can  easily  expand  all  function  calls  <f  args> 
into  <[f  argsj>  by  a  trivial  macro. 

Suppose  that  we  know  that  zero  is  an  integer  and  that  if  n  is 
an  integer  then  nvi  is  an  integer.  Ke  would  like  to  find  an  integer  j 
which  is  not  zero. 

<assert  [  integer  0 

<assert  <ccnseauent  [n] 

[integer  [♦  tv  1 J ] 

<goc\l  [integer  ?n]>» 

<prog  [f<non  0>  j]] 

Ll<goal  [ integer  ?j]» 

j  gets  the  walue  [<-0  1] 

<GOAL  ? 

Igoal-pattern  1  irecj  [-•"PATH5'  jstate-pathj  ]j>  is 
exactly  lieke  GOAL  except  that  it  returns  <>  instead  of  backtracking 
if  it  runs  cat  of  alternatives. 

<GCALS> 

returns  as  its  value  a  list  c£  the  specifications  of  the  currently 
active  goals. 

<S0BG0AL 

-clauses->  attempts  to  Batch  the  first  element  of  each 
clause  in  turn  to  the  elements  of  the  list  of  currently  active  goals. 


'na»cr^>-awcw'-' 
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If  the  first  element  of  a  clause  Batches  then  execution  continues  with 
the  remaining  elements  of  that  clause. 

5. 2. 2  Control  Primitives 

<3«ITCa 

(cev-state-pathi  (expression^  evaluates  (expression! 
asing  the  J new-state- path j  to  do  retrievals  froa  the  data  base.  At 
any  given  time  PLAHKEB  expressions  are  being  evaluated  in  a  state 
path.  A  top  level  process  begins  by  using  the  primarv  data  base  as 
its  state.  It  can  switch  into  a  local  state  by  using  the  the  function 
SBITCH.  Tree  structures  of  local  states  can  be  created  by  using  the 
function  STATEPBOG.  states  can  be  conceptualized  as  a  linear  list  of 
changes  to  the  data  base.  Thus  there  can  be  several  inconpatible 
states  of  the  world  simultaneously  under  consideration.  Although  the 
tree  structure  of  the  local  states  can  be  conceptualized  as  a  linear 
list  of  changes,  it  is  actually  implemented  more  efficiently  so  that 
the  retrieval  time  for  assertions  is  essentially  independent  of  the 
size  and  number  of  local  states.  The  assertions  in  the  data  base  are 
tagged  as  tc  which  states  they  are  in. 

<STATE> 

returns  as  its  value  a  new  local  state. 

<PRIB1BY> 

is  the  ptinary  state  of  the  system. 

<CPDATE 


>1,  «* 
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{state'll  $state21>  updates  fstatelj  into  |state2|.  If 
the  second  argument  is  aissing  the  global  data  base  is  assuaed. 

<GAT1 

|x]>  is  the  value  of  Jx}  unless  |x|  fails  siwpl?  in 
which  case  it  is  <>.  the  expression  SJxi  is  an  abbreviation  for  <GATE 
Ul>. 


JSCblock  (<oblist  gate!->  <oblist>)> 

<define  gate  <function  oat  £*x] 

<failpoint  £  }  <> 

[aessage  activation?] 

<cond 

[<not  <or  .message  .activation?» 
; "neither  the  aessage  nor 
activation  are  on* 
<.out  <» 

;"exit  gate  with  f also"  ]» 

<eval  .x> 

;"the  value  of  gate  is  the  value  of  .x  unless 
the  evaluation  of  x  fa.ils» 

lS<end-block> 


<cond  £-i"eIse"  <fail>]>  fails  with  the  aessage  <>. 

<cond  [<fail>  3]  £'.»else"  7]>  fails 

<cond  [6<fail>  3]  £-»*elsc*  7  ]>  evaluates  to  7. 

<cond  £<>  3  ]>  evaluates  to  <>. 

<cond  £<>  3]  [-»"else*;  4]>  evaluates  to  4. 

<cond  [-»"else"  <fail>]  £-»welse"  5]>  fails. 

<cond  £S-»"else"  <fail>]  [•’■‘•else*  5  ]>  evaluates  to  5. 


<TESPBCG 

♦checker*  ♦activation- aaae*  [-declarations-]  -body-> 
is  like  the  function  PBGC  except  all  assertions  and  erasures  that  are 
aade  within  the  scope  of  the  function  TE8P8QG  are  undone  when  the 
function  TE8PB0G  returns.  The  function  TBSPS06  is  useful  for  dealing 
with  hfpotheticals.  Suppose  that  we  wanted  to  establish  [all  x  [o  x]] 


"HITLER  WOULD  HAVE  BEEN  CRAZY 
TO  INVADE  ENGLAND" 


3  9-7-tc. 
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b  aathesat ical  induction. 


<goal  [p  0  ]> 

;"first  try  to  prove  [p  0  ]" 

Cteaprog  [  k  <arbitrary  <integer»] 

;"let  k  be  an  arbitrary  integer" 

<assert  [p  ,k]> 

;"assert  that  p  holds  for  k" 

<goal  [p  !•<♦  .k  1>]> 

;"try  to  prove  that  p  holds  for  k*1n> 

<SHITCH 

Jstate-pathl  } expression  1 >  causes  jexpressionl  to  be 
evaluated  with  |state-pafch|  as  its  current  local  state  path.  The 
value  of  PATH  1-STATE  is  the  current  state  path.  Local  states  are 
useful  for  handling  contra-to- factual  conditionals  and  tor 
siaultanecusly  lanipulating  inconsistent  states  of  the  world. 
Assertions  affect  only  the  state  which  is  the  first  element  of  the 
state  path  in  which  the  assertion  is  evaluated.  The  following  assigns 
the  identfier  si  the  value  which  is  a  local  state  path  in  which  Hitler 
invaded  England. 


<switch 

<_  :s1  [<state>  ! . pathl-state ]> 

<assert  [invade  Hitler  England ]» 

He  further  suppose  that  Hitler  is  crazy.  This  could  be  expressed  by 
doing  the  assertion  within  si  and  assigning  the  result  to  s2: 


<s witch 

<_  :  s2  [<state>  !  .si  ]> 

<assert  [crazy  Hitler ]» 

Mow  if  we  ask  if  Hitler  is  crazy  in  the  state  path  si,  the  answer  is 
that  he  is  not;  but  he  is  crazy  in  the  state  path  s2. 
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<switch  .si  <current  [crazy  Hitler  ]»  fails 
<switch  .s2  Ccurrent  [crazy  Hitler ]»  is  true 
<switch  .s2  <current  [invade  Hitler  England ]>>  is  true 
<switch 

[<1  .s2> ] 

<current  [invade  Hitler  England]»  fails 

<switch 

[<1  .s2>] 

<curcent  [crazy  Hitler ]>>  is  true 

<svitch 

[<2  .s2>  <1  .s2>J 

<current  f'zazy  Hitler ]>>  is  true 


Erasures  affect  tbe  first  local  state  of  the  state  path  in  which  they 
are  evaluated.  After 

<svitch  .si  <erase  [invade  Hitler  England  j»  we  have 


<svitch  .si  <current  [invade  Hitler  Bngland]»  fails 
<switcb  .s2  <current  [invade  Hitler  England ]>>  fails 

If  we  know  that  a  forwula  of  the  fora  [or  |z|  ly|]  is  true  and 
we  want  to  establish  a  goal  of  the  fora  lgj  then  we  could  write: 


<PBOG  £ ] 

<TEHPBOG  [ ] 

<ASSB81  | X | > 

<GO*I  Jg | >> 

<TEKPBQG  [  j 

<ASSE8.T  y> 

<GOAL  | g | >> 

<ASSEBT  Jg  J» 

The  above  fora  of  disjunction  eliaination  is  often  used  when  y  is  of 
the  fora  [HOT  ]x]].  Goals  of  the  fora  [or  ]x)  |y{]  can  be  established 
as  follows: 


<PHOG  [ ] 

CTEKPHOG  [ ] 

<ASS EBT  [  HOT  J  X  |  ]> 
<GOAL  y» 

<ASSEBT  <CLA9SB  [J  |X]  Jy|»> 


5.2.2. 1  Failure  Primitives 


<UMIQDE>  fails  if  the  current  goal  is  not  unique  among  all  the 
goals  that  are  currently  active. 

CUHICOE 

< 1 p |  -args->  Jplace|>  fails  if  the  procedure  | p i  with 
arguments  -args-  is  not  unique  among  all  the  procedures  that  are 
active  in  'place).  The  ] place)  can  be  a  process  or  it  can  be  [BETBEEN 
Inamel)  |name2|]  in  which  case  only  the  procedures  between  Inaaelj  and 
|name2|  are  be  examined. 


<BETRY 

)activation| >  causes  failure  to  Jactivation)  which 
must  include  the  call  to  BETRY  within  its  scope.  Execution  resumes 
with  the  beginning  of  the  named  block. 


<prog  here  [a] 

< _ a  3> 

<prog  there  [  ] 

<cond 

[ <is?  4  .a> 

<.here  .a> 

;"exit  .here  with  .a"]> 

<_  :  a  4> 

<retry  .there»>  evaluates  to  4 


5. 2.2.2  Finalize  primitives 
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<?IHALIZ£ 

*activat±on-name*>  causes  fill  actions  that  have  been 
taken  in  the  block  ^activation- name*  to  be  finalized  and  then  returns 
the  value  of  ♦activation- sane* .  Thus  <<FIHU,1IZE  +activation~na*e+>  - 
values->  Mill  finalize  all  the  actions  that  have  been  taken  in  the 
scope  of  ♦activation-nanev  and  then  exit  *activation-name*  with  - 
values-.  Actions  which  are  finalized  are  not  undone  if  a  failure 
backs  up.  Finalization  can  be  useU  to  save  storage  for  actions  which 
should  not  be  automatically  reverted  in  case  of  failure.  For  example, 
robot  thinking  for  a  given  task  is  often  divided  into  tao  phases:  a 
planning  phase  and  an  action  Dhase.  In  PLANBEB  this  is  typically  done 
by  having  the  planning  phase  return  as  its  value  a  PBOCEDUBE  vnich  is 
to  be  executed  in  the  action  phase.  Asset  ions  which  record  events 
which  have  taken  place  in  the  "real  world"  should  be  finalized  in  the 
action  phase  as  they  happen. 

5. 2. 2. 3  Bepetition  Primitives 

<FOB 

♦checker*  ♦activation-name*  [-declarations-] 

[-f or-specif ications- 

[-•"CUSSEHT"  JpatternJ  |state-path|  ] J 

-body-> 

is  the  for  statement  of  PLAHIEB.  For  each  assertion  in  the  data  base 
that  matches  |pattern|  the  -body-  is  executed*  For  example  the 
following  statement  placem  all  the  bricks  on  brick  1  is  the  blue  box. 


<for 


[[<brick>  x]] 
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[[-■••current"  [on-top-of  _x  brickl]]] 
<pick-up  .  x> 

<place-in  <•  [blue  box]>» 


<PEHSIST 

♦checker*  ♦activation- nave*  [-declarations-] 
[[-."INITIAL"  -initial-action-] 

[ -•"TEST"  ]  test]  -test-action- ] 

[-."LIST"  jiteaj  condition] 

[ -."STEP"  -step-action-] 

[-"FINAL"  -final-]] 

-body-> 

where  ♦activation-naae*  and  ♦checker*  are  optional  is  equivalent  to 
the  following; 


<PHQG  ♦checker*  *activation-naae* 

[-declare tions- 
[  COLLECTED  ()]] 

; "initialize  COLLECTED  to  [ ] 

<FAILPOI NT 

[ MESSAGE  ACTIVATION ] 

<COND 

[<B0T?  <0B? 

. BESSAGE 
•  ACTIVATIOS» 

-f inal- 

<• ♦activation-naae* 

•CC1LBCTED> 

;"exit  .  ♦hctivation-naae*’  with 
.collected  "]» 

-body- 

<COSD 

[I  test | 

-test-action- 

<.  ♦activation-naae*  .COLLECTEO 
;"ezit  . ♦activation-naae* 
with  .collected"  ]> 

<COMD 

[ | condition | 

;"if  the  condition  is  set 
then  add  itea 
to  the  end  of  COLLECTED" 
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<_  *  COLLECTED  ( ! . CCLLBCTED  itea)>]> 
-step-action- 
<FAIL> 

;"generate  a  sisple  failure"> 

"Are  all  the  blocks  in  boxt  green?"  translates  to 


<persist  bl  [T<block>  hll 

[[-"final"  <.1)1  6  ;"exit  .bl  with  t"]] 

<goal  [in  _b  boxt]> 

;"find  a  block  in  boxt" 

<cond 

[6<goal  [green  .b]> 

;"if  the  block  is  green  then 

continue  with  the  loop"  ] 

f -"else" 

<£ail  <>  .b1> 

; "other wise  generate  a  failure  out  of 
the  persist  loop"]» 


<FIHD 

♦activation- naae+ 

[-declarations- ] 

r 

[-"QUAHTITI  1  quantity | ] 

[-"LESS"  | lower-bound j  -fewer-] 

[ -"GBEATEB"  |upper-bound |  -*ore-J]] 

Jiteil 

-body-> 

constructs  a  list  of  between  J lower!  and  J upper]  jitenjs  according  to 
the  ]body|.  The  FIBD  -  c  *  '  function  is  equivalent  to  the 

following: 


<STBAIGHTEH  <PBOG  ♦activation- naie> 

[-declarations-  [HOHBEB  0]  [COLLECTED  ()  ]  ] 
<f ailpoint  []  <>  [s  A] 

<C0HD 

[<N0T?  <OB?  .H  .  A>> 


V 
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collected"  ]» 


<COHD 

[<HOT?  <IS? 

Iguantity | 
-'"hLL"» 

<FAIL>]> 

;"if  the  quantity  sought 
is  not  all 
then  backtrack" 

CCOND 

[<IS? 

<LESS  |lover-bound |> 
. H0HBEB> 

-less- ]> 

<.+activation-naae+ 

. CCLLECTEO> 

; "return  with  the  items 


-bod  y- 

<_  : COLLECTED  (!  .COLLECTED  |itea|)> 

<IHC  1-PEBSISTENT  HUI1BEB> 

<COND 

[<IS?  Iguantity 1  .NUHBEB> 

<.+activation-naae*  . C0LLBCTED> 

;"if  have  found  the  quantity 

desired  then  return  the»"]> 

<CCHD 

[CIS?  <GHE  ATER  | upper-hound  1 >  . NUHBEB> 
-a ore-  ]> 

<FAIL>» 


"Find  three  boxes  that  contain  green  blocks." 


translates  to: 


<f ind  [[ <box>  x]  [<block>  bjl  [[-."QUANTITY"  3]]  .x 
<goal  [box  _x]> 

<goal  [contains  .x  _b]> 

<goal  [green  ,b]» 


5. 2. 2. 4  Eulti-Process  Priaitives 


In  aore  coaplicated  situations,  we  find  that  it  is  convenient 
to  be  able  to  have  aore  than  one  PLABNBB  process. 


5.2  pi.ge  235 


<FAIL 

j«essage|  Jplacel  jfuncfcionJ>  generates  a  failure  with 
|ae:>sagej  to  the  j place]  at  the  last  point  that  execution  left 
IplaceJ.  If  the  process  which  called  FAI.L  is  ever  resuaed  with 
arguaents,  then  it  begins  by  applying  ]f unction]  to  the  arguments. 


<EXHADST 

♦checker-*  +activation-na»e+  [-declarations-] 

[ [ -'"INITIAL"  -initial-action- ] 

[-'"TEST"  {test]  -test-action-] 

[-"ACTION"  -action-] 

[-».  ‘LIST"  Jiteai  |condition|  ] 

[-•"STEP"  -step-action- ] 

[-•"FINAL"  JfinalJ]] 

-body-> 

attempts  to  execute  -body-  once  for  each  tine  that  -action-  is 
successfully  evaluated.  Every  tiae  that  the  body  it  executed  the 
function  EXHAUST  sends  a  sinple  failure  to  the  action  to  see  if  it  has 
any  alternatives.  An  EXHAUST  loop  is  very  nuch  like  a  PEBSIST  loop 
which  is  defined  above.  Both  loops  are  driven  by  the  failure 
■echanisn.  The  main  difference  is  that  the  effects  of  srecuting  the 
body  .  PEBSIST  loop  are  not  preserved  because  a  failure  »ust 
prop*.  ,ace  through  the  body  before  it  can  be  executed  again.  In  an 
EXHAUST  loo  .  separate  process  is  created  for  the  action  so  that  the 
effects  of  -  .-5_.  i ting  the  body  can  be  preserved.  The  function  2XHADST 
is  eguivalen:  to  the  following  expression: 


<P80G  ^checker*  +activation-na«e+ 
l 

[COLLECTED  {)  ] 

[<proc> 

[  ACTIO B-PBOCESS  <PBOCESS  ,  ACTIOB-FO|ICTICR>  ] 
[TAL-PBOC  <.  ACTION-PBOCESS  <PSOCESS»  ]  ]  ] 
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; "declare  COLLECTED  to  be  initialized  to  [  ]" 

ACTION -PRO CESS  is  the  naae  of  the 

process  which  is  tv  be  exhausted  by  failure" 

;"start  the  PLANNEE  process  . ACTION-PROCESS  in 
which  the  action  is  executed  with 
the  naae  of  this  process 

as  an  argument  so  that  it  can  later  resume 
this  process" 

;"we  expect  one  value  to  be  returned 
which  we  shall  call  VAI.-PROC" 

<EEPEAT  [ ] 

<COND 

(CIS?  EXHAUSTED  .VAl-PBOO 
~f inal- 

C.b  .CCLLECTED> 

;"exit  .b  with  .collected"] 

[I  test' 

-tes t-action- 
;"if  the  test  is  met 

then  execute  the  test-action1* 

C.b  «CCLLECTED> ]> 

-bod  y- 
CCOND 

(  Icondition I 

c_  :COLLECTED  (!. COLLECTED  |item|)>]> 

;"if  the  condition  is  act  then  add  the  itea  to  the  end 
of  the  list  of  collected  items" 

CFAIL 

<> 

.ACTICN-PBOCESS 

<F UNCTION  [Y]  <_  ; VAI-PHOC  ,Y»> 

; "suspend 

execution  of  the  current  process 

and  begin  failing  from  the  point  within 

the  action  process 

where  execution  last  left  off"» 

The  following  function  is  defined  so  that  we  can  start  off  the 
evaluation  of  the  action  process. 

CDEFINE  ACTION-FUNCTION 

[FUNCTION  [ [ <proc>  MAIN]] 

CFAILING?  (<?>  C.  MAIN  EXHAUSTED>]> 

;°when  the  action  finally  is  exhauseted 

resuae  the  process  .MAIN  with  the  value  EXHAUSTED  and 
terminate  the  action  piocess" 

-action- 
< . MAIN  SUCCESS> 

;"resu«e  the  main  process  with  the  value  SUCCESS"  ]> 
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Suppose  that  we  want  tc  disprove  a  proposition  «p  using  likely 
coun  terexaaples.  Furtheraore  we  would  like  to  work  on  each 
counterexanple  in  parallel  as  it  is  found. 


<exhaust  disprove  [c] 

<goal  [ likely-counter-exanple  _c  .  p]> 

-« |  <ccnd 

[S<goal  ,c> 

<tea porize 

.disprove> 

-»Mf  ound-counter-exaaplen>>  ]» 
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5.3  Clauses  in  PLANNEE 


He  would  like  to  explore  the  potentialities  for  using  PLANNER 
to  control  a  resolution  based  deductive  system.  Since  the  question 
whether  or  not  a  given  foraula  is  a  theorem  or  not  is  undecidable,  a 
complete  proof  procedure  using  resolution  for  the  first  order 
quantificational  calculus  aust  in  general  be  rather  inefficient.  In 
fact  any  unifora  proof  .procedare  for  the  first  order  guantif icational 
calculus  can  be  sped  up  by  an  arbitrary  recursive  function  for  alaost 
all  proofs.  The  result  on  the  necessary  inefficiency  of  a  coaplete 
proof  procedure  should  be  sharpened  up.  Hew  theoretical  to^ls  aust  be 
developed  in  order  to  aake  any  substantial  advance  on  the  problem. 

The  importance  of  resolution  as  a  prcblea  solving  technique  does  not 
lie  in  the  fact  that  it  appears  to  be  the  fastest  known  uniform  proof 
procedure  for  first  order  loqic.  Rather,  resolution  provides  one 
technique  for  dealing  with  the  logic  of  disjunction  and  instantiation. 
Domain  dependent  procedures  aust  provide  most  of  the  direction  in  the 
computation  to  attempt  to  prove  a  theorea.  Se  shall  introduce  new 
actors  to  match  clauses; 

<CLADSB 

-patterns-  Jrest-of-dis junctsj >  matches  a  clause  only 
if  it  has  disjuncts  which  match  -patterns-  and  the  rest  of  the 
disjunctc  match  the  pattern  |rest-of-dis juncts* • 


<prog  £  y  ] 
< 


Cclause  [subset  a  ;y]> 

<ciause  [x]  [subset  ?x  b]>» 

y  gets  the  value  b 

x  gets  the  value  a 

<CLA CSE-OP 

ijt-atj  Jdis juncts-that-Batch-pat J  | rest-of-disjuncts |> 
aatches  a  clause  such  that  the  clause  of  the  disjurcts  that  Batch 
jpatj  in  turn  Batch  the  pattern  jdis juncts-that-Batch-pat]  andthe 
clause  of  the  the  rest  of  the  disjuncts  Batch  | rest-of-disjuncts |. 

The  following  functions  are  used  to  aanipulate  clauses. 

<CLA  USE 

[-declarations-]  -disjuncts~>  returns  a  copy  of  a 
clause  with  the  variables  declared. 

<VABIABLES 

(clause j>  returns  the  variables  in  the  clause. 

<1 SSTANTI ATE 

{clause | >  returns  a  copy  of  the  clause  with  all  of  its 
variables  instantiated  with  unique  constants  of  the  appropriate  type. 

<fiESOLVE 

-clause-specif ications->  results  in  resolving  the 
clauses  represented  by  the  clause  specifications  together  to  yield  a 
clause  which  is  returned  as  the  value  of  the  function  resolve.  A 
clause  specification  is  the  literal  of  the  clause  which  is  tc  be 


unified. 
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<EOR-BESOL?ENT 

♦checker*  ♦activation- name*  [-declaratiicns-  ] 

[[ -»" CLAUSES"  -clause-specifications-] 

[-"BESOIVEKT"  JresolventlJ 
-f or-loop-speci£ications- ] 

-body-> 

attempts  to  execute  the  body  of  the  for  statement  once  for  each  result 
of  resolving  clauses  that  meet  the  clause  specifications  to  produce  a 
clause  which  matches  the  pattern  resolvent. 

It  is  possible  for  PLAHHEB  to  rnn  out  of  things  to  evaluate 
before  it  has  deduced  the  null  clause.  A  cosplete  proof  procedure 
could  be  called  to  try  to  finish  off  the  proof.  If  in  the  course  of 
its  operation,  the  complete  procedure  generates  a  clause  that  matches 
the  antecedent  of  a  theorem  then  PLABHZB  can  be  re-invoked.  The 
complete  procedure  could  be  run  in  parallel  with  PLANNEB.  Thus  using 
7LAHBEB  we  could  implement  a  complete  proof  procedure.  The  point  is 
that  implementing  any  "reasonable"  proof  procedure  should  be  easy  in 
PLAKREB.  However,  we  should  not  rely  on  a  uniform  proof  procedure  to 
solve  our  problems  for  us. 


APSHOT  NO. 


FAIL 


SNAPSHOT  NO. 
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5.4  A  Simple  Example 


5.4.1  Using  a  Consequent  Theorem 

Suppose  that  we  know  that  [subset  a  b],  [subset  ad],  [subset 
b  c]#  and  [all  [functicn  <bccle>  [[<set>  x]  [<set>  y]  [<set>  z]] 
[implies  [and  [subset  ?x  ?y]  [subset  ?y  ?z  ]  ]  [subset  ?x  ?z]]]]  are 
true.  How  can  we  get  PLANNEfi  to  prove  that  [subset  a  c]  holds?  We 
would  give  the  system  the  following  theorems. 


given: 


[subset  a  b] 

[subset  ad] 

[subset  b  c] 

<asscrt  <define  backward 

Cconseguent  [[<set>  x  y  z]]  [subset  ?x  ?z] 

<unigue> 

{"the  current  goal  must  be  unique" 

<goal 

[subset  ?x  ?y] 

[-."use"  -."current"  backward  <?>  ]> 

<goal 

[subset,  .y  ?z  ] 

[-."use"  -."current"  backward]> 

<assert  [subset  .x  .z]  [-."try"  <?>]»» 

Now  if  we  ask  FLANNEP  to  evaluate  <goal  [subset  a  c  ]>  then  we  obtain 

the  following  protocol: 
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<goal  [subset  a  c]> 

<current  [subset  a  c  ]> 
fail 

<achieve  [subset  a  c]> 
enter  backward 
x  becomes  a 
z  becomes  c 
<unigue> 

<goal  [subset  a  ?y]> 

<curreat  [subset  a  ?y  ]> 

node  1,9 

y  becomes  d 
<goal  [subset  d  c]> 

<current  [subset  d  c  ]> 
fail 

<achieve  [subset  d  c ]> 
enter  backward 
x  becomes  d 
z  becomes  c 
<unigue> 

<goal  [subset  d  ?y]> 

<current  [subset  d  ?y ]> 
fail 

<achieve  [subset  d  ?y ]> 

enter  backward 

x  becomes  d 

z  becomes  ?y 

<unigue> 

fail 

fail 

node  1,9  ;note  that  this  ncde  appears  above 
y  becomes  b 
<goal  [subset  fc  c]> 

<current  [subset  b  c]> 

<assert  [subset  a  c  ]> 
succeed 

After  the  evaluation  the  data  base  contains: 

[subset  a  b] 

[subset  a  dj 
[su'  -et  b  c] 

[si  et  a  c] 

In  other  words  the  first  thing  that  PLANNBB  does  is  to  lock  for  a 
theorem  that  it  can  activate  to  work  on  the  goal.  It  fi"ds  backward 
and  binds  x  to  a  and  z  to  c.  Then  it  makes  [subset  a  ?y]  a  subgoal 
with  the  recommendation  that  backward  should  be  used  first  to  try  to 
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achieve  the  subgoal.  The  systep  notices  that  y  sight  be  d,  so  it 
binds  y  to  d.  Next  [subset  d  c  ]  is  made  a  subgoal  with  the 
recommendation  that  only  backward  be  used  to  try  to  achieve  it.  Thus 
backward  is  called  recursively,  x  is  bound  to  d,  and  z  is  bound  to  c. 
The  subgoal  [subset  d  ?y  ]  is  established  causing  backward  to  again  be 
called  recursively  with  x  bound  to  d  and  z  determined  to  be  the  same 
as  what  the  old  value  of  y  ever  turns  out  to  be.  But  now  the  system 
finds  that  it  is  in  trouble  because  the  new  subgoal  [subset  d  ?yj  is 
the  same  as  a  subgoal  on  which  it  is  already  working.  So  it  decides 
that  it  was  a  vistake  to  try  to  prove  [subset  d  c]  in  the  first  place. 
Thus  y  is  bound  to  b  instead  of  d.  Now  the  system  sets  up  the  subgoal 
[subset  be]  which  is  established  immediately.  He  use  the  above 
example  only  to  show  how  the  rules  of  the  language  work  in  a  trivial 
case.  If  we  were  seriously  interested  in  proving  theorems  ir.  PLANNEE 
about  the  lattice  of  sets,  then  we  would  construct  a  finite  lattice  as 
a  model  and  use  it  to  guide  us  in  finding  the  proof. 

5.4.2  Using  an  Antecedent  Theorem 

-  .  »  t  v 

Suppose  we  give  PLANNER  only  the  following  theorems. 


given: 


[subs  a  b] 
[subset  c  d] 


<assert  <define  forward-right 

<antecedent  [[<sefc>  x  y  z]]  [subset  _y 

<goal  [subset  ?x  .yj> 

<assert 
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[subset  .x  .2] 

[-'"try"  forward-right  forward-left ]»>> 


<assert  <define  forward-left 

Antecedent  £[<set>  x  y  z]]  [subset  _%  _y  ] 

<goal  [subset  ?y  .z]> 

<assert 

[subset  .x  . z] 

[-•"try"  forward-right  f orward-lef t  ]>»> 

How  if  PLAHHEfi  is  asked  to  the  theorem  evaluate  <assert  [subset  be] 

[-’•"try"  <?>]>,  we  obtain  the  following  protocol: 


<assert  [subset  b  c]> 

<draw  [subset  b  c  ]> 
enter  forward-right 
y  becomes  b 
z  becomes  c 
<goal  [subset  ?x  b  ]> 

<current  [subset  ?x  b  ]> 
x  becomes  a 
<assert  [subset  a  c  1> 

<draw  [subset  a  c]> 
enter  forward-right 
y  becomes  a 
z  becomes  c 
<goal  [subset  ?x  a  ]> 

<current  [subset  ?x  a  ]> 
fail 

enter  forward-left 
x  becomes  a 
z  becomes  c 
<goal  [subset  c  ?z  ]> 

<proved  [subset  c  ?z  ]> 

7  becomes  d 
''cssert  [subset  a  d]> 

<draw  [subset  a  d]> 
enter  forward-right 
y  becomes  a 
z  becomes  d 
<goal  [subset  ?x  a ]> 

<current  [subset  ?x  a]> 
fail 

enter  forward-left 
x  becomes  a 
y  becomes  d 
<goal  [subset  d  ?z]> 

<curreat  [subset  d  ?z]> 
fail 
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fail 

succeed 

After  the  evaluation  the  data  base  contains: 

[subset  a  b] 

[subset  c  d] 

[subset  a  d] 

[subset  be] 

[subset  a  c] 

Theorems  in  FLAHKEB  can  be  proved  in  much  the  sa»e  way  used 
for  ordinary  tbeoreas.  For  example  suppose  that  we  had  the  following 
two  theorems: 

<assert  <define  th4  <ccnseguent  [[<set>  a  c]]  [subset  ?a  ?c] 

<goal  [set  ?a]> 

<tewprog  [[<cbject>  [x  <arbitrary  <object»]J] 

<assert  [eleaent  .x  .a]  <?» 

<goal  [eleaent  .x  ?c  ]>> 

<assert  [subset  .a  .c]  <?>»» 


The  function  AEBITBABY  generates  a  unique  symbol  which  has  the  type  of 
its  argument.  On  entrance  tc  the  function  TEHPROG  the  identifier  x  is 
bound  to  a  freshly  created  symbol.  The  above  theorem  is  a 
constructive  analogue  of 

[all  [function  <boole>[[ <set>  a]  [<set>  c]] 

[implies 

[all  [function 
<boole> 

[[<object>  x]] 

[implies  [element  ?x  ?a][  element  ?x  ?c]]] 
[subset  ?a  ?c}]]]] 


Going  in  the  opposite  direction,  wc  have 


<assert  <define  th4-5  <antecedent 
[[<set>  a  b]] 

[subset  a  b] 

<assert 

Antecedent 

[[<elcaent>  x]] 
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[eleaent  ?x  ?a] 

Assert  [eleaent  ?x  ?b  ]  <?»  a»>>> 

Assert  <define  th4-6  Antecedent 
[[<s»t>  a  b]] 

[subset  a  b] 

Assert 

Consequent 

[[<eleaeut>  xj] 

[eleaent  ?x  ?b] 

<goal  [eleaent  ?x  ?a  ]>  b»»> 

Assert  <define 
th3 

Consequent  [[<object>  xj[<set>  r  s]] 

[element  ?x  ?s ] 

<goal  {element  ?x  ?r  ]> 

<goaI  [subset  ?z  ?sj> 

Assert  [eleaent  .  x  .  s]  <?»»> 

The  above  the ore*  is  a  constructive  analogue  for 


[all  [function 
<boole> 

[[<object>  x]  [<set>  s]] 
f inplies 

[sole  [function 
<toole> 

[[ <set>  rj] 

[and  [eleaent  ?x  ?r]  [subset  ?r  ?s]]] 
[eleaent  ?x  ?s}]jj] 

?roa  th3  and  th.3  can  p  ove  the  following  theorem: 

<consequent  [[<s.jt>  a  b  c ]  1  [subset  ?a  ?c  ] 

<goal  [subset  ?a  ?bj> 

<goal  [subset  .b  ?c  ]> 

<assert  [subset  ,a  .c]  <?»> 

The  above  theorea  is  a  ccnstrucvive  analogue  for 

[all  [function 
<boole> 

[[<set>  a]  [<set>  bj  [<set>  c)] 

[ implies 

[and  [subset  'em  ?b ;  [subset  ?t>  ?c]) 

[subset  ?a  7c]]]] 
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Often  we  treat  the  statement  of  a  theorea  siaply  as  an  abbreviation 
for  the  proof  of  the  theorea. 

Be  would  like  to  exawine  the  previous  problea  froa  the  point 
of  view  of  resolution  based  deductive  systea.  The  actor  CLAUSE  aatchs 
clauses.  It  uses  the  fact  that  disjunction  is  coaautative  and 
associative.  He  have: 


[not  [eleaent  ?x  ?a]] 
[eleaent  ?x  ?b  ]> 


2.  <clause  [[<set>  a  b]l 

[eleaent  [eleaent- of -difference  ?a  ?b  ]  ?a  ] 

[subset  ?a  ?b]> 

3.  <clause  [[<set>  a  i]j 

[not  [eleaent  [eleaent-of-difference  ?a  ?b  ]  ?b]] 
[subset  ?a  ?b]> 

<assert  <define  necessary 
<antecedent 

[literal 1  literal2  ] 

<clause  <al 1  [subset  {?} ]  _iiterai1>  <?>> 

<_ 

<clause 

<all 

{not  [subset  [?}  ]] 
_litera.\2> 

<?» 

<clause  [[<sot>  a  o]  [<objcct>  xj] 
[not  '-obset  .  b]] 

[not  •  eleaent  ?x  .a]] 
[eleaent  ?x  .b]» 

<assert  <resolve  .literall  .literal2»»> 


The  above  theore a  says  that  we  should  eliainate  all  positive  instances 
of  the  predicate  subset  froa  clauses.  It  is  a  special  case  of 
theoreal  which  ha t  been  partially  coapiled. 
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Causer t  <define  sufficient 
antecedent 

[[<set>  a  bj  literal 1] 

<clause  <all  [not  [subset  _a  _b]]  _literal1>  <?» 

<prog  [literal2] 

<_ 

Cciause  <all  [subset  {?}  ]  __literal2>  <?>> 
<clause  [[<sv’t>  i  b]] 

[subset  .a  .b] 

[ eleaent 

[eleaent-of-differeace  .a  .b] 
.a  ]>> 

<assert  <resolve  .  literall  .literal2»> 

<prog  £literal2J 
<_ 

<ciause  <all  [subset  [?}  ]  _literal2>  <?» 
<claose  [[<set>  a  b]] 

[subset  .a  . b] 

[not  [eleaent 

[eleaent-of-difference  .a  .  bj 
.b]]» 

<assert  <resclve  .literall  .literal2»>^» 

The  above  theorea  says  that  ve  should  eliainate  all  negative  instances 
of  the  predicate  subset  froa  clauses. 


5.4.3  Using  Eesolution 


Ve  shall  assuae  that  the  resolution  routines  autoaatically 
detect  contradictory  pairs  of  clauses  aben  they  are  generated.  The 
theorea  [iaplies  [and  [subset  &  b]  [subset  b  cj]  [subset  a  c]]  an  oe 
proved  as  follovs: 


<prog  [  j 

<teaprog  [[<set> 

[a  <arbitrary  <set»] 

[b  <arbitrarj  <set»] 

[  n  Arbitrary  <set»]]] 

<assert  <clause  []  [subset  .a  .b]>  [-•"try11  <?>]> 
<assert  <clause  [3  [subset  «b  ,cj>  [ '•‘‘try"  <"?>]> 
<assert  <clause  £J  [not  [subset  .a  *cjj>  [-‘•try"  <?>]> 
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<goal  <clause>» 

<assert  Cclause  [[Cset>  :  y  z]] 

[not  [subset  ?x  ?y  ]  ] 
[not  [subset  ?y  ^z]) 
[subset  ?x  ?z]>>> 


The  proof  is: 

4.  <clause  [  ] 

[subset  a  b]> 

5.  Cclause  [[<set>  x]1 

[not  [element  ?x  a  ]  j  [element  ?x  b  ]>  by  1.  and  4o 

6.  Cclause  [  ] 

[subset  b  c  ]> 

7.  Cclause  [[<set>  xj] 

[not  [element  ?x  1  ]]  [element  ?x  c  ]>  by  1.  and  6. 

8.  Cclause  [  ] 

[not  [subset  a  c]]> 

9*  ^CldUS6  £  J 

[element  [ elenent-of-dif ference  a  c]  a]>  by  8.  and  2. 


10.  Cclause  [  ] 

[element  [elenent-of-dif ference  a  c]  b ]>  bv  8.  and  3. 


11.  Cclause  M 

[not  [element  [ element-of-difference  a  c]  c]J>  by  10.  and  7. 


12.  Cclause  M 

[not  [element  [elex.-nt-of-dif ference  a  c]  b]J>  by  9.  and  5. 


13.  Cclause  [  ]>  by  12.  and  IQ 
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5.5  Hyths  about  PLANNfiH 


5.5.1  Consequent  Theorems  Are  Used  Only  for  Working  Backwards 

We  would  like  to  give  an  example  to  show  that  the  computation 
trse  that  EIAKNES  defines  as  it  executes  theorems  does  not  necessarily 
correspond  to  the  tree  of  the  intuitive  solution  space  which  is  being 
investigated.  The  example  hich  we  use  is  the  farmer,  goat,  cabbage, 
and  wolf  problem.  We  worked  out  the  following  solution  with  Jeff 
Hulifson.  The  problem  begins  with  a  farmer  on  the  side  of  a  stream 
with  a  boat,  a  wolf,  a  goat,  and  cabbage.  The  farmer  wants  to 
transport  them  all  across  the  stream  in  the  boat.  The  boat  can  only 
hold  one  of  them  besides  the  farmer.  The  wolf  will  eat  the  goat  and 
the  goat  will  eat  the  cabbage  if  the  farmer  is  not  there  to  interfere. 
How  can  the  farmer  get  them  all  across  the  stream?  He  begin  by 
evaluating  <goal  [  frcm  t  t.  t  t  ]>  which  means  to  set  up  a  goal  to  make 
a  move  from  the  postion  where  all  four  objects  '  ■  e  oa  the  same  side  of 
the  tank. 

<assert  <define  make-move  Cconsequent  make 

[wolf  goat  cabbage  farmer] 

[from  ?wol£  ?goat  ?cabbago  ?far£.“9r] 

<goa\  (safe  .wolf  .goat  .cabbage  . farmer ]> 

;*make  sure  the  current  situation  is  safe" 

<cond 

[<and? 

<is?  <>  .wolt> 

<is?  <>  . goat> 

<is?  <>  . cabbage> 

<is?  <>  ,farmer>> 


•qr-c 
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<.aake  t> 

;"exi*-  .sake  with  t"]> 

;"if  they  are  all  safely  on  the  other 
side  of  the  river  return  t" 

<cond 

[<current?  [looked-at 

.  wolf 
.  goat 
.cabbage 
.£ araer  ]> 

<.aake  <>> 

;"exit  .aake  with  <>"]> 

;"if  we  have  already  looked  at  this  situation 
return  <>  which  is  false" 

<assert  [looked-at  .wolf  .goat  .cabbage  .faraer ]> 

<ct 

6<cond 

[<is?  .faraer  .goat> 

;**if  the  faraer  is  on  the  saae  side 
as  the  goat/ 

then  he  can  carry  the  goat  with 
hia  tc  the  other  side" 

<goal  [ f roa 

.wolf 

<not?  . goat> 

.cabbage 

<not?  .  f  araer>  ]>  ]> 

6<goal  [froa 
.volt 
.goat 
. cabbage 

<not?  .faraer>]> 

&<cona 

[<is?  .faraer  .wolf> 

;"siailarly  if  the  faraer  is  on  the  saae  side 
as  the  wolf" 

<goal  [froa 

<not?  .volf> 

.goat 

•cabbage 

<not?  ,faraer>]>]> 

t><cond 

[<is?  .faraer  .cabbage> 

<goal  [froa 

.wolf 

.goat 

<not?  .cabbage> 

<not?  .  faraer>  }>  ]>> 

;"the  function  OB  tries  the 

possibilities  in  order»> 
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<assert  <define  safety-check  <consequent  safety-check 

[wolf  goat  cabbage  faraer] 

[safe  ?wolf  ?goat  ?cabbage  ?far*erj 
<cond 

[  <or? 

<and? 

<is?  .wolf  <not?  .faraer» 

<is?  .wolf  .goat.>> 

<and? 

<is?  .goat  <not?  .£araer» 

<is?  .goat  .cabbage>» 

;"the  situation  is  not  safe  if  either 

the  wolf  is  on  the  opposite  side 
fro*  the  farier 

but  on  the  sane  side  as  the  goat  or 
the  gdat  is  on  the  opposite  side  froa  the 
farmer  but  on  the  saae  side  as  the  cabbage1* 
<fail  <>  ,safety-check>  ]»» 

The  protocol  of  the  solution  is: 


<goal  [froa  t  t  t  t]> 

<goal  [fro*  t  O  t  <>]>  goat 

<goal  [froa  t  t  t  t  ]>  goat 
<goal  [froa  t  <>  t  t]>  hiaself 

<goal  [froa  t  <>  t  <>]>  hiaself 
<gcal  [fret  <>  <>  t  <>]>  Wv  If 
<goal  [froa  <>  t  t  t]>  goat 

<goai  [fro*  <>  <>  t  <>]>  goat 
<goal  [froa  <>  t  t  <>]>  hiaself 

<goal  [frou  <>  t  t  t  ]>  hiaself 
<goal  [froa  t  t  t  t]>  wolf 
<goai  [fro*  <>  t  <>  <>]>  cabbage 

<goal  [froa  <>  t  <>  t  ]>  hiaself 

<goal  [froa  <>  <>  <>  <>J>  goat 

note  that  there  are  several  things  wrong  with  the  above  procedure. 

For  one  thing  the  problea  solver  should  work  forwards  and  backwards 
simultaneously  trying  to  find  necessary  conditions  for  a  solution  as 
well  as  sufficient  condtions.  The  procedure  is  not  very  swart  in  the 
way  that  it  goes  about  looking  for  a  solution.  These  ills  can  be 
cured  in  various  ways.  The  reader  night  find  it  instructive  to 
consider  soae  of  the  possibilities. 


r 
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5.5.2  PLANNED  Does  only  Depth  First  Search 

PLANNEB  runs  under  a  backtrack  control  structure.  Because  of 
the  control  structure  the  execution  tree  of  a  process  leeks  like  a 
depth  first  investigation.  However,  by  creating  more  processes  the 
growth  of  the  set  of  execution  trees  can  be  quite  arbitrary.  As  an 
exaaple  we  can  convert  the  above  solution  to  the  farmer,  goat, 
cabbage,  and  wolf  problea  to  breadth  first  investigation  by  evaluating 
the  arguments  to  OR  in  parallel  instead  of  sequentially  in  the  theorea 
HAKE-HOVE. 

5.5.3  Ose  of  Failure  laplios  Inefficient  Search 

The  failure  primitive  in  PLANNER  is  a  method  of  transferring 
control.  The  concept  does  not  have  any  necessary  relation  to  program 
errors  such  as  dividing  by  zero.  Often  a  proof  by  contradiction  is 
completed  by  generating  a  failure  back  to  an  label  function  with  a 
message  like  *  happiness”  when  the  contradiction  is  detected.  The 
message  is  caught  when  it  propagates  back  to  the  point  where  the  proof 
by  contradiction  was  set  up.  The  effect  of  the  failure  is  to  get  rid 
of  all  the  garbage  that  is  generated  in  the  proof  by  contradiction. 

In  a  similar  vein  the  failure  mechanism  is  often  used  as  a  summarizing 
mechanism.  At  certain  points  along  the  computation,  certain 
conclusions  are  derived  from  the  process  of  investigation.  These 
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conclusions  can  be  lifted  cut  of  the  details  that  were  used  to  derive 
then  by  failing  with  values  vhich  summarize  shat  has  been 

learned.  Then  the  coaputation  can  continue  with  a  cleaner  slate. 

For  example  in  a  chess  program,  exploration  of  the  possible  moves 
might  reveal  that  our  gueen  is  pinned  against  our  king  threatening  the 
loss  of  the  queen.  Information  to  that  effect  would  be  passed  back 
with  the  failure. 

5. 5.  K  PLAHHEB  Dc^s  Only  Hhat  It  Is  Told 

In  a  strict  sense  PLASNEB  does  only  what  it  is  told  to  do. 
There  is  no  random  element  or  independent  consciousness  built  into  the 
primitives .  However,  because  of  the  goal  oriented  nature  of  the 
foraalisa  it  is  very  difficult  to  predict  what  a  large  body  of  PLAHNEB 
theorems  will  do.  In  fact  one  of  the  more  obnoxious  things  that  can 
happen  is  that  some  theorems  find  a  nonobvior  ;  way  to  accomplish  a 
trivial  goal.  Usually  this  happens  because  there  is  a  bug  in  the  code 
for  the  obvious  way  to  achieve  the  goal. 
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6.  Acre  on  PLAHNEB 


6. 1  PLAHHEB  EXAMPLES 


6.1.1  London's  Eridge 


Host  of  the  tiae  we  decide  which  stateaents  we  want  to  erase 

on  the  basis  of  the  -unifications  of  the  stateaents.  If  we  erase 

stateaent  a,  s  3  stateaent  b  depends  on  stateaent  a  because  a  is  part 

of  the  justification  of  b,  then  we  probably  want  to  erase  stateaent  b. 

Soaetiaes  a  decision  is  aade  on  the  basis  of  other  criteria.  For 

exaaple  suppose  that  we  carefully  reaove  the  bottoa  brick  free  a 

coluan  of  bricks.  He  shall  suppose  that  each  brick  is  of  unxt  length. 

The  stateaent  [at  (brick]  (place!  J height!  ]  will  be  defined  to  aean 

that  brick  | brick!  is  at  place  (place]  at  the  height  (height J. 

Suppose  that  have  the  following  tbeoreas: 

[at  brickl  here  0] 

[at  lrick2  here  1j 

[at  brick3  here  2] 

<define  london' s-bridge 
<erasing 

[ 

[<brick>  brick  other-brick] 

[<place>  place] 

[<integer>  height]] 

[at  _brick  _pJoce  ^height  ] 

<er«ss 
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[at 

_other-brick 
. place 

<add?  ,height>] 

[-.use-*  <?>]> 

;"erase  the  fact  that  there  is  another  brick 
in  the  place  above  brick" 

<assert 

[at  .other-brick  .place  ,height]> 

; "assert  that  it  is  where 

brick  osed  to  be"» 


Thus  after  <erase  [at  fcrickl  here  0]>  we  will  have  [at  bricv.2  here  0] 
and  [at  brick3  here  1],  The  upper  bricks  in  ':he  tower  have  all  fallen 
down  one  level.  The  above  example  coaes  froa  a  suggestion  aade  by  S. 
Pa pert. 


6.1.2  Analogies 

6. 1.2.1  Simple  Analogies 

our  next  example  illustrates  the  usefulness  of  the  pattern 
directed  deductive  systea  that  PLAHNEH  uses  compared  with  the 
guantif icat ional  calculus  of  order  omega.  Be  are  interested  in  simple 
analogies  such  as  those  explored  by  Tom  Evans.  Given  that  object  al 
has  some  rexation  to  object  a2  and  that  object  cl  has  the  same 
relation  to  object  c2,  the  problem  is  to  deduce  that  at  is  analogous 
to  :1.  Be  use  the  predicate  test-analogo"?  within  the  theorem  pair  to 
record  that  we  think  two  objects  might  be  analogous  and  that  we  would 
like  to  check  it  out.  Suppose  that  we  give  PIAMKEB  the  following 


theorems: 
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<def ine 


<derine 


[inside  al  a2] 

[inside  cl  c2  ] 

[a-ob ject  al  ] 

[a-cbject  a2 ] 

[c-object  cl] 

[ c-ob ject  c2] 

j?air  Consequent  pair 

[<object>  a  c] 

[<functor>  predicate] 

[  {?}  argsal  argsa2  argscl  argsc2]] 

[analogous  ?a  ?c  ?predicate] 

<unigue> 

;"the  current  goal  oust  be  unique" 

<cond 

[<current?  [test-analogous  ?a  ?c]> 

;"if  a  and  c  are  test-analogous  then 
we  are  done" 

C.pair  done> 

;"exit  .pair  with  done"  ]> 

<current  [a-ob ject  ?a ]> 

<current  [c-object  ?c]> 

;"£ind  an  a-object  and  a  c-object" 

<assert  [test-analogous  .a  ,c  ?predicate]> 
<current  [?preuicate  !_argsa1  .a  !_argsa2]> 
<current  [ .predicate  !_argsc1  .c  !_argsc2]> 
;"find  a  predicate  in  which  both  a  and 
c  are  arguaents" 

<cond 

[<is?  <non  [  ]>  ,argsa1> 

<gcal  [corresponding-analogous 
.argsa  1 
.argscl 

.  predicate  J>  ]> 

<cond 

[<is?  <non  [  ]>  .argsa2> 

<gcal  [corresponding-analogous 
. argsa2 
,argsc2 

.predicate  ]>]> 

; "show  that  the  other  arguments  are  analogous" 
<assert  [analogous  .a  .c  .predicate ]»> 


chop-of f-another  <conseguent 

[<objecr>  a  b] 

[  (?)  aa  bb  ] 
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[<functor  <?>  <?>>  predicate]] 
f corresponding-analogous  [?a  ??aa]  [ ?c  ??cc]  Tpredicate  ] 

<cond 

[Ccurrent?  [test-analogous  ?a  ?c  ?predicate]> 

;5!if  a  and  c  are  currently  test-analogous  then 
ve  only  have  to  look  at 
the  rest  of  the  elements"  ] 

[-•"else" 

<current  [analogous  ?a  ?c  ?predicate  ]>  ]> 

<ccnd 

[<is?  <non  [  ]>  .aa> 

<current  [corresponding-analogous 
?aa 


?cc 

?predicate  ]>  ]»> 


Thus  if  ve  ask  PLAHHE8  to  evaluate  <goal  [analogous  al  ?x  inside  ]> 
then  x  will  be  bound  to  cl  in  accordance  with  the  following  protocol: 


<goal  [analogous  al  ?x  inside ]> 
enter  pair 
a  gets  the  value  al 
c  gets  the  value  ?x 
predicate  gets  the  value  inside 
<unigue> 

<current  [ test-analogous  al  ?c  inside ]> 
FAIL 

<current  [a-object  a1]> 

<current  [c-cbject  ?c  ]> 

node  1 

c  gets  the  value  c2 
x  gets  the  value  c2 

<te«porary  [test-analogous  al  c2  inside]> 

<current  [inside  al  a2]> 

<current  [inside  cl  c2]> 

<goai  [corresponding-analogous  [a2]  []  inside  1> 
enter  chop-of f-another 
FAIL 

FAIL 

node  1;  note  that  this  node  appears  above 
c  gets  the  value  cl 
x  gets  the  value  cl 

<te»porary  [test-analogous  at  cl  inside ]> 

<current  [inside  cl  c2]> 

<goal  [corresponding-analogous  [a2]  [c2]  inside ]> 
enter  chop-of f-aa^ther 
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a  gets  the  value  a2 
c  gets  the  value  c2 

<current  [test-analogous 

a2 

c2 

inside  ]> 

FAIL 

<current  [analogous  a2  c2]> 
enter  pair 
a  gets  the  value  a2 
c  gets  the  value  c2 
<nnique> 

<current  [ test-analo^nus 

a2 

c2 

inside ]> 

FAIL 


<current  [a-object  a2]> 

<current  [c-object  c2]> 

<teaporary  [ test-analogous  a2  c2  inside  ]> 
<current  [inside  al  a2]> 

<current  [ inside  cl  c2  ]> 

<goal  [correspoinding-aaaxogous 

[al] 

[Cl] 

inside  ]> 

enter  chop-off-another 
a  gets  the  value  al 
c  gets  the  value  cl 
<current  [test-analogous  al  c1]> 
succee  d 


In  the  process  of  carrying  out  the  evaluation  the  following  additional 
facts  will  be  established:  [analogous  al  cl  inside]  and  [analogous  a2 
c2  inside].  The  reader  night  find  it  causing  to  try  to  fornulate  the 
above  problea  in  the  first  order  guantif icational  calculus. 


6.1.  2.2  Structural  Analogies 


The  process  of  finding  analogous  proof:;  and  aethods  plays  a 
very  iaportant  role  in  t.heorea  proving.  For  exaaple  the  proofs  of  the 
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unigueness  of  the  identity  eleaent  and  inverses  in  seai-groups  are 
closely  related.  The  definitions  are: 

[equivalent  [identity  e]  [equal  £*  a  e]  [*  e  a]  a]] 

[iiplies  [identity  e]  [equivalent  [inverse  hi  b]  [egua*  [*  bl  b]  [*  b 
bl  ]  e]]j  If  e  and  e*  are  identities,  then  we  have  [equal  e  [*  e  e* ] 
e*  J.  If  al  and  al*  are  inverses  of  a*  then  we  have  [equal  al  [*  al* 
a  al]  al].  The  general  fora  of  the  analogy  is  [equal  w  _string  w* J 
where  .string  algebraicly  siaplifies  to  w  and  w*.  In  aany  cases 
analogies  are  found  by  construction.  That  is  the  problen  solver  looks 
around  for  problens  that  aight  be  solved  with  an  analogous  technique. 
In  other  words  we  will  have  a  aethod  of  solution  in  search  of  a 
problea  that  it  can  solve!  How  that  we  have  found  a  technique  for 
proving  that  various  kinds  of  eleaents  are  unique,  let  us  look  around 
for  a  siailar  problea  to  akich  our  technique  applies.  lie  find  that 
zeros  in  seai-groups  are  defined  as  follows: 

[equivalent  [zero  z]  [equal  £♦  a  z]  £*  z  a]  z]]  Supposing  that  z  and 
z*  are  zeros  we  find  that  [equal  z  [*  z  z*]  *•].  Cne  najor  problea  in 
the  effective  use  of  analogies  in  order  to  solve  probleas  is  that  it 
is  very  difficult  to  decide  when  and  at  what  level  of  detail  to  try 
for  an  analogy.  Another  problea  is  that  often  the  analogy  holds  only 
at  a  quite  abstract  level  and  it  aost  not  be  poshed  too  far.  Consider 
the  following  two  algorithas: 

<define  nuaber-  of-ataas 
[function  [z] 

<cond 
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[<>’>«pty?  .  x> 

0] 

[<is?  l*ato«  .  x> 

1] 

[  ->Ke  lse" 

<♦ 

<nunber-of-a toas  <1  .x» 
<nuaber-of-atoas  <r  st  .  x»>]>]> 

<define  list-of-atous 
[function  £x] 

<cond 

[<eapty?  .x> 

[33 

[<is?  !=utoa  ,x> 

[•*33 

[  -•"else" 

<append 

<list-of-a toas  <1  «x» 
<list-of-atoas  <rest  .x»>]>]> 


The  functions  nuaber-of-atoas  and  Xist-of-atcas  are  precisely 
analogous.  In  aost  cases  two  functions  will  not  be  nearly  so 
sinilar.  Very  few  of  the  ideas  of  one  will  be  used  in  the  other. 
Struct oral  analogies  aay  also  be  constricted  by  procedural  abstraction 
[see  chapter  7].  Bledsoe  has  suggested  that  still  another  exaaple  of 
analogous  proofs  is  found  in  the  Schwartz  inequality: 


<nonoecr easing 
<expt 

<♦ 

<*  <x  1>  <y  1» 
<♦  <x  2>  <y  2>» 


<expt  <x  1>  2> 
<-.  <x  2>  2» 

<♦ 

<-  <y  1>  2> 

<-  <y  2>  2»» 


<no  decreasing 
<expt 
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Ve  can  foraulatc  the  principle  of  aatheaatical  induction  for 
the  integers  in  the  following  way: 


<define  induction  cconseguent  [p] 

[for-all  _p  ] 

<teaprog  [[a  <arbitrary  <integer»]] 
<goal  i'<. p  0» 

<assert  !*<.p  ,a>> 

<goal  !*<.p  !•<♦  ,a  1>»> 
<assert  [for-all  .p]»> 
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If  we  are  given  the  facts  [  =  <♦  0  0>  0]  and 


<clause  [x  y] 

[  = 

<♦  ?y  <♦  ?x  1>> 

<♦  <+  ?y  ?x>  1>]> 

then  we  can  establish 


[for-all  <function  [n]  [=  <♦  0  ?n>  ?n]>]. 


The  following  theorea  will  do  induction  on  s-expressions: 


<define  expr-induction 
<conseguent 
[p] 

[for-all  _p] 

<tenprog 

[[a  <arbitary  <aton»]] 
<goal  ! ' < . p  .a>>> 


<teaprog 

C 

[car  <arbitrary  <expr»] 
[edr  <arbitrary  <expr>>j] 


<assert  !*<.p  .car» 

<assert  !»<.p  .cdr» 

<goal  ! •  <. p  I’<cons  .car  .cdr»» 
<assert  [for-all  .  p]»> 


Be  would  like  to  try  to  do  without  existential  quantifiers.  Be  can 
eliainate  then  in  favor  of  Stolen  functions  in  assertions  and  in  favor 
of  PLAMIKB  identifiers  in  goals.  The  problea  of  finding  proofs  by 
induction  is  foraally  identical  to  the  problea  of  syntesizing  prograns 
out  of  "canned  loops".  The  process  of  procedural  abstraction  [which 
is  explained  in  chapter  7]  has  an  analogue  which  is  "induction 
abstraction"  [finding  proofs  by  induction  frea  exaaple  proofs  written 
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out  in  full  without  induction]. 


6.1.4  Descriptions 


6.1.  4.1  Structural  Descriptions 


PLANNEE  can  be  used  to  find  objects  fro»  partial  or  schematic 
descriptions.  The  stateaent  [perpendicular  [line  _a  _b  ]  [line  _c 
d  ]  ]  will  be  defined  tc  aean  that  the  lines  [line  .a  .b]  and  [line  .c 
,d]  are  perpendicular.  The  BATCHLESS  function  <ASSIGNED?  arg>  tests 
to  see  if  the  identifier  arg  has  a  value.  We  shall  adopt  the 
convention  that  [glued  a  b]  leans  that  bricks  a  and  b  are  glued 
together  and  f orthogonal  [line  |a|  |bj]  [line  IcJ  Id]]]  leans  that  the 
lines  between  the  centers  of  bricks  ]a|  and  Jb]  is  orthoganal  to  the 
line  between  the  centers  of  bricks  ]c|  and  |d|.  A  three-corner  is 
defined  to  be  a  group  of  three  bricks  joined  together  such  that  two  of 
thei  are  diagonal  to  each  other.  A  three-corner  is  shown  in  figure  1. 
In  other  :>ords  the  following  is  a  description  of  a  three-corner: 

<define  find-three-corner 
<conseqoent 

[£<brick>  a  n  c]] 

[three-corner  ?a  ?b  ?c] 

<goal  [glued  ?a  ?b  ]> 

<prog  again  [ ] 

<goal  [glued 

.a 

<all  <non  .b>  ?c>]> 

<goal  [orthogonal  T line  .a  *b]  [line  .a  .c]]> 

<cond 

[<cr? 


6<goal  [ glued 


A  Three-  Corner  *. 

[cube  I]  [glued  I  23 

[cube  23  [glued  2  33 
[cube  31 


A  STICK  : 

[cube  4]  [glued  4  53 

[cube  53  [glued  5  63 

[cube  6]  [glued  6  73 

[cube  73 


ANOTHER  STICK’. 

[cube  83  [glued  8  93 
[cube  93  [glued  9  103 
[cube  103 
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.a 

<all  <non  .b>  <non  .c>>]> 
5<goal  [glued  .b  <non  .a>]> 

S<goal  [glued  .c  <non  .a>]>> 

<f  ail  <>  again>  ]»» 


The  description  can  be  used  in  the  obvious  way  to  find  three-corners. 
The  siateaent  [stick  _a  _b J  is  defined  to  aean  that  .a  and  ,b  are  end 
bricks  of  a  line  of  bricks  and  [between  _a  ^b  _c ]  is  defined  to  aean 
that  brick  . b  is  between  bricks  .a  and  .c.  Exaaples  of  sticks  are 
shown  are  shown  in  figure  1. 


<define  find-stick 

<conseguent 

[[ <brick>  a  b]  [ !  =  fix  n]J 
[stick  ?a  ?b  _n  ] 

<current  [brick  ?a]> 

<current  [brick  ?b]> 

<goal  [stick-segaent  .a  .b  <-  .n  2>]> 
<assert  [stick  .a  .b  .n]>» 

<define  fiad-stick-segaent 
<conseguent  find 
[[<brick>  x  y  w][!»=fix  n]] 

[stick-segaent  ?x  ?y  _n] 

<cond 

[<is?  <neg>  ,n> 

<f ail>  ] 

[6<goal  [glued  ?w  ?.•:]> 

<goal  [orthogonal 

[line  .x  .u] 

[line  .x  ?y]]> 

<fail>  ] 

[6<goal  [glned  ?x  ?y]> 

<cond 

[ <and? 

<goal  [glued  ?w  ?yj> 

<goal  [orthogonal 

[line  .y  .w] 

[line  .y  .x]]» 

<fail> ]> 

<. find  t> 

;"exit  .find  with  t"  ]> 

<goal  [glued  ?w  .x  ]> 
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<goal  [between  .x  .w  .y]> 

<goal 

[ stick-segaent  .a  .y  <-  .n  1>] 
[•-use-'  find-stlck-segaent  <?>J»> 


6. I.a.2  Constructing  Examples  cf  Descriptions 


Given  a  description  of  a  structure  [such  as  a  stick]  we  would 
like  to  be  able  to  derive  a  general  aethod  for  building  the  structure. 
The  problea  of  deriving  such  general  construction  aetbods  f»-oa 
descriptions  is  very  difficult.  In  this  case  we  we  can  construct  a 
stick  of  length  n  with  ends  x  and  y  using  the  functions  <CGLDE  facel 
face2>  which  glues  tht  value  of  facel  to  the  value  of  face2  and  the 
function  new-brick  which  produces  a  new  brick. 


<define  aake-stick  Cconseguent  aake 
[[<brick>  x  y  a  ]  [  !=f ix  n]] 
[aake-stick  _x  _y  _n ] 

<cond 


[<is?  <less  3>  .n> 

<glue  [ bot*oa  ,x]  [top  .y]> 
<• aake  t> 

;"exit  .aake  with  t"]> 

<is  _w  <new-brick>> 

<g*ue  [bottoa  .x]  [top  .w]> 

<goal  f  aake-stick  _w  _y  C-  u  !>]»> 


6. 1.4. 3  Descriptions  of  Scenes 


S.  Papert  has  suggested  that  theorea  proving  techniques  Bight 
be  applied  to  the  problea  of  analyzing  2-diaensional  projections  of  3- 
diaensional  bricks.  In  this  section  ae  fill  give  a  foraal  definition 
of  the  problea.  idolpho  Guxaan  has  developed  a  prograa  [called  SEE] 


6. 1  page  268 


which  tries  to  solve  such  problems  :any  humans  solve  such  problems 
by  mentally  constructing  a  symbolic  3-dimensional  scene  which 
of  ..a -rally  projects  back  to  the  given  2-diiensional  input.  3e  define  a 
brick  to  be  a  connected  open  o  pa  gee  region  of  ’-space  bounded  by  a 
finite  number  of  pla'  ~  such  that  if  t  # o  planes  intersect  then  they 
must  be  orthogonal.  -  the.mor^  the  complement  of  a  brick  is 
required  to  be  connect  m.  ‘ii>u  h*. i  is  are  allowed  to  have  holes  in 

them,  A  3-dieensional  scene  -  arrangement  of  bricks  such  that  no 

/ 

two  of  them  intersect.  A  2-diaeasional  scene  is  a  collection  of 
straight  lines  in  a  plane.  A  2-dimensional  projection  is  the  optical 
projection  of  a  3-dimensional  scene  onto  a  plane.  A  statement  p  about 
3-dimensional  scenes  Kill  be  said  to  be  valid  for  a  2-dimensional 
scene  r  if  for  all  3-dimensicnal  scenes  t  such  that  t  projects  to  r  it 
is  the  case  that  p  is  true  for  t.  A  two  dimensional  scene  rO  will  be 
said  to  be  ambiguous  for  a  language  1  if  it  is  the  projection  of  two 

3-dimensional  scenes  tl  and  t2  such  that  there  is  a  sentence  pO  in  1 

with  pO  true  i"  tl  and  false  in  t2.  There  are  a  number  of  primitive 
predicates  that  should  be  included  in  a  language  for  scene  analysis: 
[parallel  z  y]  means  that  x  and  y  are  parallel. 

[coplanar  z  y]  means  that  x  and  r  are  coplanar. 

[normal  planel  directed-linesegment ]  means  that  the  normal  of 
pi an el  is  in  the  direction  of  the  directed-linesegment. 

[restricted  plar.el  ptl  pt2  pfc3  ]  means  that  the  normal  to 
planel  is  restricted  to  the  angle  ptl  pt2  pt3. 

[sape-brick  region  1  region2]  moans  that  regionl  and  region2 


are  part  of  the  saae  brick. 

[adjacent  regionl  region2J  leans  that  regicnl  and  region2  are 
regions  of  the  saae  brick  that  intersect  at  right  angles. 

[convex  regionl  region2]  leans  that  regionl  and  region2  are 
regions  of  the  same  brick  that  intersect  at  right  angles  to  lake  a 
convex  body. 

[concave  regionl  region2]  leans  that  regionl  and  region2  are 
regions  of  the  saie  brick  that  intersect  at  right  angles  to  lake  a 
concave  body. 

[element  x  y]  means  that  x  is  an  element  of  y. 

[in-frcct-of  brickl  brick2]  means  that  brickl  is  in  front  of 

brick2. 

[resting-on  brickl  brick2]  means  that  brickl  is  resting  on 

brick2. 

[on-top-o£  brickl  brick2]  leans  that  brickl  xs  on  top  of 

brick2. 

[subset  x  y]  leans  that  x  is  a  subset  of  y. 

[coordinates  point  1  coordl  ]  if>ns  that  point  1  has  3- 
dimensional  coordinates  coord  1. 

1 he  following  statements  about  exaiplel  are  valid  as  can  be  seen  by 
considering  vhere  the  nonals  of  the  planes  light  lie  and  deducing 
consequences  until  contradictions  are  found. 

[nonax  a  [direction  7  13]] 

[ noraal  b  [direction  12  13}] 

[convex  a  b] 


7 


6  ./p-'Up  'i-'te 


I 


[convex  a 
[convex  b 
[ normal  c 
[normal  d 
[normal  e 
[convex  d 
[normal  £ 
[convex  d 
[convex  e 
[normal  b 
[ normal  g 
[convex  g 


c] 

C] 

[ direction 
[ di rection 
[ direction 

e] 

[ direction 

*] 

f  3 

[ direction 
[ direction 


10  13]] 
7  4  ]  ] 

2  4]] 

3  4]] 


16  1833 
15  1633 


The  following  statement  about  example  1  satisfiable: 


[and 

[resting-on  [brick  a  b  c]  [brick  e  £  d33 
[resting-on  [brick  a  b  c]  [brick  g  h  3 3 3 

The  following  statements  about  example  2  are  valid: 

t convex  a  c  3 
convex  a  b] 

[convex  b  cj 

[normal  a  [direction  12  1433 
[normal  c  [direction  3  1433 
[convex  g  h] 

[ normal  g  [ direction  5  633 
[normal  h  [direction  8  633 
[not  [adjacent  c  d 3 3 
[not  [adjacent  b  d 3 3 
[convex  4  ej 
[convex  e  fj 
[convex  d  f  3 

[normal  e  [direction  4  13  33 
[normal  d  [direction  S  1333 
[normal  f  [direction  11  1333 


The  following  statement  about  example  2  is  satisfiable 


[  and 

[same-region  c  g3 
[same-region  b  hj 
[same -brick  a  b  c 


9  h33 


r 
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The  three  dimensional  coordinates  of  points  are  obtained  by 
using  more  than  one  camera  to  Tie*  the  scene  or  using  a  focus  nap.  In 
the  case  where  we  have  coordinates  as  a  prinitive  predicate,  the 
definitior  of  a  projection  of  a  3-dinensional  scene  aust  be  modified 
to  inclade  the  3-diiensional  coordinates  of  all  the  projected 
vertices.  in  the  case  where  we  have  the  three  diaensional  co¬ 
ordinates  of  the  projected  verti-jes,  we  can  deduce  that  two  planes  are 
part  of  the  sane  brick  if  they  intersect  at  an  acute  right  angle. 

Since  the.  object  that  is  being  viewed  night  be  so  far  aray  that 
accurate  coordinates  cannot  be  obtained,  a  deductive  system  should  be 
developed  which  does  not  use  coordinates.  At  the  very  nininun  a  hard 
core  deductive  system  for  the  analysis  of  2-dimensional  projections 
should  be  consistent  and  every  valid  statement  should  be  proveabre. 
That  is  every  theorem  cf  the  system  snould  be  satisfiable  [there  is  a* 
least  one  interpretation  that  satisfies  the  theorevj.  Interest  in 
questxous  of  satisfiability  comes  from  the  fact  that  some 
interpretations  are  far  'aore  likely  than  others  in  the  real  world. 
Statements  that  are  to  be  tested  for  satisfiability  must  be  made  as 
strong  as  possible  in  order  to  provide  a  meaningful  cest.  Althouah 
the  linking  rules  are  mathematically  very  elegant,  in  their  present 
form  they  do  not  adequately  represent  the  semantics  of  the  optical 
projection  rules.  The  value  of  the  program  by  Guzman  is  that  it 
provides  c  ijectures  about  which  regions  are  satisfiable  in  the 
relation  sa?e- brick,  However,  the  program  suffers  because  it  does  not 
have  any  explicit  knowledge  of  optics.  Be  would  advocate  an  approach 
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that  aakes  greater  use  of  deduction  to  test  the  validity  or 
satisfiability  of  a  sentence.  Questions  of  satisfiability  and 
validity  of  sentences  with  respect  to  any  given  projection  are 
decidable  since  the  theory  of  real  closed  fields  is  decidable. 
Efficient  algoritheas  should  be  developed  to  test  whether  a  given 
sentence  is  valid  or  satisfiable  in  a  projection. 


6. 1.4.4  Power  Set  of  Intersection  of  Two  Sets  Is  the  Intersection  of 
Their  Power  Sets 


The  following  exaaple  was  proposed  by  W.  Bledsoe.  Prove  that 
the  power  rot  of  the  intersection  of  two  sets  is  the  intersection  of 
their  power  sets.  He  shall  use  cap  as  a  synonya  for  intersection. 


<define  extensionality-conse  Cconseguent  [[<3et>  x  yl] 

[=  ?y] 

<goal  [subset  ?x  ?yj> 

<goal  [subset  ?y  ?x]> 

<assert  [  =  .  x  .  y]>» 

<define  eleaent-power-conse  Consequent  [[<set>  z  all 
[eleaent  ?x  [power  ?a]] 

<goal  [subset  ?x  ?a  ]> 

<assert  [eleaent  .x  [power  ,a]]>>> 

<define  eleaent-power-ant  <antecedent  [[<set>  z  all 
[eleaent  ?x  (power  ?a]] 

<assert  [subset  ?x  ?a]»> 

<define  subset-cap~ccnse  <coi sequent  [[<set>  a  b  cj] 
[subset  ?c  [cap  ?a  ?b]] 

<goal  [subset  ?c  ?a ]> 

<goal  [sukset  ?c  ?b]> 

<assert  (subset  .c  [cap  .a  .b]]»> 

<define  subset-cap-ant  <antecedent  [[<set>  a  b  cl] 
[subset  _c  [cap  _a  _b]] 


<assert  [subset  .c  .a]> 
<assert  [subset  .c  ,b]»> 
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<define  subset-cap-conse  Consequent  [[<set>  a  b  c]] 
[subset  ?c  [cap  ?a  ?b]] 

<goal  [subset  ?c  ?a  ]> 

<goal  [subset  ?c  ?b]> 

<assert  [subset  .c  [cap  .a  .b]]>» 

<define  eleaent-cap-ant  Antecedent  [x  [<set>  a  b]] 
[eleaent  _x  [^.ap  _a  _b]] 

<assert  [eleaent  „x  .a]> 

<assert  (decent  . x  .b]>» 

<define  eleaent-ca p-conse  <ccnseguent  [x  [<set>  a  b]] 
[eleaent  ?x  [cap  ?a  ?b]J 
<goal  [eleaent  ?x  ?a]> 

<goal  [eleaent  ?a  ?b]> 

<assert  [eleaent  ?x  [cap  ?a  ?b]]»> 

<de£ine  subset-conse  Consequent  f[<set>  a  b]] 

[subset  _a  ?b] 

<teaprog  [x  Arbitrary  <?»] 

Assert  [eleaent  .x  ,a]> 

<goal  [eleaent  .x  ,b]» 

<assert  [subset  .a  .b]»> 

Be  can  non  set  up  our  goal  to  prove  the  theorea: 


<goal  (= 

[cap  (power  al]  [power  a2]] 

[power  [cap  al  a2]]]> 

The  goal  will  produce  the  following  protocol: 

enter  extensionality-conse 

x  becoaes  [cap  [power  al]  [power  a2]] 
y  becoases  [power  [cap  al  a2]] 

<goal  [subset  [cap  [power  al]  [power  a2]][ power  [cap  al  a2]]]> 
enter  subset-conse 

a  becoaes  [cip  [power  al]  [power  a2]] 
b  becoaes  [power  [cap  al  a2]] 
x  becoaes  gl 
<assert 

[ eleaent 

9  » 

[cap  [power  al  ]  (power  a2]]]> 
enter  eleaent-cap-ant 
x  beccaes  gl 
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a  becomes  [power  al] 
b  becoaes  [power  a2  ] 

<assert  [eleaent  gl  [power  a1]]> 
enter  eleaent-power-ant 

<assert  [subset  gl  a1]> 
<assert  [eleaent  gl  [power  a2  ]  ]> 
enter  eleaent-power-ant 

<assert  [subset  gl  a2]> 


<goal  [eleaent  gl  [power  [cap  al 
enter  eleaent-power-conse 
x  becoaes  gl 
a  becoaes  [cap  al  a2 ] 
<goal  [subset  gl  [cap  al 
enter  subset-cap-conse 
c  becoaes  gl 
a  becoaes  al 
b  becoaes  a2 
<goal  [subset  gl 
<goal  [subset  gl 
<asssrt 

[subset 


jl  a2]> 

a2  ]  ]  ]> 


a2]]> 


al  ]> 
a2]> 


<assert 


[eleaent 


<assert 


<goal 


[subset 


[subset 


[power  [cap  ai 


[cap  [power  al]  [power 
[ power  [ cap  al  a2  ]]]> 


gi 

[cap  al  a2  ]  ]> 


a2]]]> 


a2]] 


[power  [cap  al  a2]] 

[cap  [power  al]  [power  a2]]]> 
enter  subset-conse 

a  becoaes  [power  [cap  al  a2]] 
b  becoaes  [cap  [power  al]  [power  a2]] 
i  becoaes  g2 

<assert  [element  g2  [power  [cap  al  a2]]]> 
enter  eleaent-power-ant 
x  becomes  g2 
a  becoaes  [cap  al  a2 ] 

<assert  [subset  g2  [cap  al  a2 ] ]> 
enter  subset-cap  ant 
x  becoaes  g2 
a  becoaes  al 
b  becoaes  a2 


<assert  [subset  g2  al  ]> 
<assext  [subset  q2  a2]> 
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<goal 

[  eleaent 

g2 

[cap  [power  al]  [power  a2]]]> 
enter  eleaent-cap-conse 
x  becoaes  g2 
a  becoaes  [power  al] 
b  becoaes  [power  a2] 

<gcal  [eleaent  g2  [power  a1]]> 
enter  eleaent-power-conse 
x  becoaes  g2 
a  becoaes  al 
<goai  [subset  g2  a1]> 

<goal  [eleaent  g2  [power  a2]]> 
enter  eleaent-power-conse 
x  becoaes  g2 
a  becoaes  al 
<goal  [subset  g2a1]> 

<assert 

[ eleaent 

g2 

[cap  [power  al]  [power  a2]]]> 

<assert 

[ subset 

[power  [cap  al  a2]] 

[cap  [power  al]  [power  a2]]]> 

<assert 

[- 

[power  [cap  al  a2]] 

[cap  [power  al]  [power  a2]]]> 


6.1.5  Seaantics  of  natural  Language 

Although  probleas  for  PLAHHEB  are  typically  phrased  in  a 
perfectly  foraal.  precise,  unaabiguous  syntax,  we  will  usually  not 
fiad  the  seaantics  as  well  defined.  If  we  say  [[very  happy]  john] 
instead  of  "John  is  very  happy.**  we  will  not  thereby  have  aade  th* 
concept  of  happiness  any  less  nebulous  for  the  aachine.  nevertheless 
it  is  convenient  for  a  problea  solver  to  have  such  concepts  although 
they  are  not  rigorously  defined.  Probleas  of  seaantic  aabiguxty  and 
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clarif icaton  can  require  arbitrary  amounts  of  computation  in  order  to 
be  adequately  resolved.  For  example  consider  the  following  simple 
example  of  how  semantic  ambiguities  can  bo  eliminated  with  the  aid  of 
"real- world*5  knowledge: 

<assert  [  is-smaller- than  hand  [pig  pen]]> 

<asser t 

<define  example- of-bar-hillel 
<antecedent  [[<object>  x  y’] 

[in  _x  _y ] 

<cond 

[ <is?  pen  .x> 

<goal  [ is-smaller-than  ?y  [pig  pen j  ]> 

<assert  [in  [fountain  pen]  .y  ]>]»>> 

Now  if  w e  assert  [in  pen  hand],  PLANNER  will  conclude  that  [in 
[fountain  pen]  hand]  is  true  since  a  hand  is  smaller  than  a  pig  pen. 
One  of  the  important  difficulties  that  have  plagued  rest  of  the 
programs  that  have  been  written  to  answer  questions  in  English  is  that 
they  are  trying  to  solve  two  very  hard  problems  at  the  same  time. 

First  they  must  make  sense  of  English  syntax  and  second  they  need  a 
powerful  problem  solving  capability  to  answer  the  question  once  they 
have  "understood"  it.  Ambiguous  cases  should  be  resolved  on  the  basis 
of  deduction  and  not  on  the  basis  of  sere  linking  scheme  such  as 
"semantic  memory".  As  it  stands  PLANNER  provides  sophisticated 
mechanisms  for  solving  problems  in  formal  languages.  A  program  could 
be  written  [perhaps  in  PLANNER?]  to  translate  English  into  PLANNER 
theorems  for  problem  solving.  Conversely  we  could  try  to  translate 
PLANNER  theorems  into  simple  natural  language.  surprisingly 
translation  into  natural  language  can  be  very  awkward  because  natural 
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DIAGRAMS  FOR  GEOMETRY  THEOREMS 


SIDE- ANGLE-SIDE 


[CONGRUENT  [  x,  x2x3J  [y3y2y;]] 


EQUAL-ANGLE 


[EQUAL  [ANGLE  p}  pgp3]  [ANGLE  p^p^] 
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language  lacks  many  of  the  descriptive  and  procedural  primitives  of 
PLANNER. 


6. 1.6  The  Pons  Asinorua 


We  would  like  to  show  how  the  nbewilderingly  simple"  proof  of 
the  pons  asinorun  [i.  e.,  base  angles  of  an  isoscles  triangle  are 
equal]  can  be  done  very  simply  in  PLANNEE.  The  following  notation 
will  be  used: 


[length  JplJ  lp2|]  for  the  length  from  point  |p1|  to  |p2| 

[angle  jxj  |y|  jzj]  for  the  angle  J x 1  |y|  |z|  which  has  the 
point  I y j  at  its  vertex 

Pour  PLANNER  theorems  are  used.  They  are  procedural  analogues  of 
axioms  in  plane  Euclidean  geometry. 


<define  side-angle-side 

Cconseguent  [xl  x2  x3  yl  y2  y3  j 

[congruent  [7x1  7x2  7x3  ]  [7y1  7y2  ?y3]] 

<unigue> 

<goal  [  =  [length  7x1  7x2  ]  [length  7y1  ?y2]]> 

<goal  [=  [angle  7x1  7x2  7x3]  [angle  ?y1  7y2  ?y3]]> 
<goal  [=  [length  7x2  7x3]  [length  7y2  ?y3]J>» 

<define  equal-angle 

<conseguent  [pi  p2  p3  w] 

[=  [angle  7p1  7p2  7p3]  ?w] 

<unigue> 

<goal  [=  [angle  ?p3  7p2  7p1  ]  ?w]>>> 


<define  equal 

Consequent  [x  y] 

£-  ?y 3 

<unique> 

<or 

<match  ?x  ?y> 

<goal  [=  ?y  ?x  ]>>>> 
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<define  angles-by-congruence 

Consequent  [pi  p2  p3  gl  g2  g3] 

[  =  [angle  ?p1  ?p2  ?p3  ]  [angle  ?g1  ?q2  ?q3]] 

<unique> 

<goal 

[congruent 

[?p1  ?p2  ?P3] 

[  ?q1  ?q2  ?q3]]»> 

Suppose  that  we  have  an  isosceles  triangle  ABC  with  the  length  of  AB 
equal  to  the  length  of  AC.  He  can  input  this  as: 


<assert  [=*  [length  A  B]  [length  A  C]]> 

The  goal  is  to  prowe  that  angle  ABC  is  eqcal  to  angle  ACB: 


<goal  [*  [angle  ABC]  [angle  A  C  B]]> 

One  protocol  for  establishing  the  goal  is: 
enter  angle~by~congruerce 
pi  becones  A 
p2  becones  B 
p3  becones  C 
ql  becones  A 
q2  becones  C 
q3  becones  B 

<goal  [congruent  [A  B  C]  [A  C  B]]> 
enter  side-angle-side 
pi  becones  A 
p2  becones  B 
p3  becones  C 
ql  becones  A 
g2  becones  C 
g3  becones  B 

<goai  [*  [length  A  B]  [length  A  C]]>  is  easy  since  it  is  in 
the  data  base 

<goal  [«  [angle  B  A  C]  [angle  C  A  B]]> 
enter  equal-augle 
pi  becones  B 
p2  becones  A 
p3  becones  C 
w  becones  [angle  CAB] 

<goal  [*  [angle  CAB]'  agle  C  A  B]]> 
enter  equal 

x  becones  [angle  CAB] 
j  becones  [angle  CAB] 


6. 1  page  280 


<goal  [  =  [  length  A  C]  [length  A  B  ]  ]> 
enter  egual 

x  becoaes  [length  AC] 
y  becoaes  [length  A  B] 

<goal  [=  [length  A  B]  [length  A  C]]>  succeeds  by 
looking  in  the  data  base 


Ira  Goldstein  has  iapleaented  a  Gerlernter-like  geooetry 
theorea  prover. 
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6.2  Current  Problems  and  Future  Work 


PLANNEE  would  benefit  greatly  from  an  efficient  parallel 
processing  capability.  The  system  would  run  faster  if  it  could  work 
on  its  goals  in  parallel.  Quite  often  a  goal  will  fail  alter  a  short 
computation  along  its  path.  The  use  of  parallelism  would  enable  us  to 
get  aany  goals  to  -ail  so  that  we  could  adopt  More  of  a  progressive 
refinement  strategy.  He  would  like  to  carry  out  computations  to  try 
to  reject  a  proposed  subgoal  at  the  same  time  that  we  are  trying  to 
satisfy  it.  flany  computations  can  be  carried  out  much  faster  in 
parallel  than  in  serial.  For  example  we  can  determine  whether  a  graph 
with  n  nodes  is  connected  or  not  in  a  time  proportional  to  <*  <log  n> 
Clog  n».  It  has  been  known  for  a  long  time  that  LISP  computations 
using  parallel  evaluation  of  arguments  are  determinate  if  the 
functions  rpiaca,  rpiacd,  and  setg  are  prohibited.  He  could  impose  a 
similar  set  of  restrictions  on  PLANNEE.  Another  approach  is  to 
introduce  explicit  parallelism  into  the  control  structure.  He  have 
**|Cr’  and  n>"  delimit  parallel  calls  for  e.'.ements  and  "|  {"  and  "},f 
delimit  parallel  calls  for  segeaents.  A  parallel  function  call  will 
act  as  a  fork  in  which  one  process  is  created  to  do  the  function  call 
and  the  other  proceeds  with  normal  order  evaluation.  For  example  in 
<*•  |  <*  3  4 >  <♦  7  8>>  we  could  compute  3*4  in  parallel  with  7+8.  The 
copy  function  could  be  sped  up  by  a  factor  proportional  to  the  number 
of  processors: 
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<define  copy  [function  [x] 

<cond 

[<is?  <»cnadic>  .  x> 

.x] 

[  '•’’else" 

[l<copy  <1  .x»  (copy  <rest  .x>}]]>]> 

However,  we  would  still  have  problems  communicating  between  the 
branches  of  the  coaputation  proceeding  in  parallel.  Partly  this  a 
problea  of  sharing  an  indexed  global  data  base  between  parallel 
processes.  Me  would  need  the  standard  lock  and  unlock  priaitives  and 
ucliaited  use  of  assigaaent  in  order  to  keep  the  computations 
synchronized.  But  if  we  allowed  the  use  of  lock  and  unlock  and 
unliaited  use  of  assigaaent,  the  prograas  aight  become  indeterminate. 
One  of  the  aost  important  properties  that  can  be  proved  about  a 
program  is  that  it  is  deterainate. 

PLANNEB  logic  is  a  kind  of  hybrid  between  the  classical  logics 
[such  as  the  guantif icational  calculus  and  iotuitionistic  logic],  and 
the  recursive  functions  [as  represented  by  the  lambda  calculus  and 
Post  productions].  The  semantics  of  P LINKER  logic  is  aost  naturally 
defined  dynamically  by  the  properties  of  procedures.  The  semantics  of 
the  guantif icational  calculus  can  be  defined  by  set  theoretic  models 
of  possible  worlds.  The  logic  of  the  guantific&tional  calculus  is 
CONSERVATIVE  in  the  sense  that  if  a  sentence  S  follows  from  a  sat  of 
sentences  fl  then  S  will  follow  from  any  superset  of  (!.  Do  to  its 
ability  to  have  conditional  expressions  that  test  the  state  of  the 
worlds  PLANNER  logic  is  HOT  conservative.  This  causes  consternation 
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anong  classical  logicians  because  many  elegant  theorems  for  classical 
logic  do  not  hold  for  PLANNEB  logic.  The  restriction  of  having  to  be 
conservative  is  quite  severe  in  problea  solving.  Suppose  that  there 
are  three  cubes  A,  B,  and  C  sitting  on  a  table.  Suppose  that  it  is 
desired  to  build  a  tower  two  cubes  high  at  place  P.  The  plan 
constructed  might  be  to  pick,  up  A,  set  it  down  at  P,  and  then  place  2  . 
on  top  of  it.  If  in  the  process  of  constructing  the  plan  we  deduced 
that  cube  A  was  glued  to  the  table  with  liguid  iron,  we  would  want  to 
change  our  plan  to  use  cubes  B  and  C  to  aake  the  tower.  But  by  the 
conservative  properties  of  ordinary  logic  the  original  plan  must 
reaain  valid.  The  only  way  around  this  would  appear  to  be  introduce 
soae  special  kind  of  internal  state  into  the  deductive  aachinery  of 
the  guantif icational  calculus.  Becoamendations  are  another  source  of 
nonconservative  behavior  in  PLANNEB.  For  exaaple  we  night  not  allow 
Sorn’s  Lemaa  to  be  used  aore  than  once  in  a  proof.  Both  PLANNEB  logic 
and  quantificational  logic  are  COMPACT  in  the  sense  that  a  computation 
[proof]  depends  on  c  :ly  a  finite  nuaber  of  expressions.  In  comparison 
with  the  guantif icational  calculus  PLANNEB  would  appear  to  be  sore 
powerful  in  the  following  areas: 

control  structure 
pattern  matching 
erasure 

local  states  of  world 

There  are  interesting  parallels  between  theorea  proving  and 
algebraic  aanipalation.  The  two  fields  face  siailar  problems  on  the 
issues  of  simplification,  equivalence  of  expressions,  interaediate 
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expression  bulge,  and  nan- machine  interaction.  The  parallel  extends 
to  tne  trade  off  between  domain  dependent  knowledge  and  efficiency. 

In  any  particular  case,  the  theorems  need  not  allow  PLANNER  to  lapse 
into  its  default  conditions.  It  will  sometimes  happen  that  the 
heuristics  for  a  problen  are  very  good  and  that  the  proof  proceeds 
smoothly  until  almost  the  very  end.  Then  the  progam  gets  stuck  and 
lapses  into  default  conditions  to  try  to  push  through  the  proof.  On 
the  other  hand  the  program  might  grope  for  a  while  trying  to  get 
started  and  then  latch  onto  a  theorem  that  knows  how  to  polish  off  the 
problem  in  a  lengthy  but  fool  proof  computation.  PLANNER  is  designed 
for  use  where  one  has  great  number  of  interrelated  procedures 
[theorems]  that  might  be  of  use  in  solving  some  problem  along  with  a~ 
general  plan  for  the  s jlution  of  the  problem.  The  language  helps  to 
select  procedures  to  refine  the  plan  and  to  sequence  through  these 
procedures  in  a  flexible  way  in  case  everything  does  not  go  exactly 
according  to  the  plan.  The  fact  that  PLANNEE  is  phrased  in  the  form 
of  a  language  forces  us  to  think  more  systematically  about  the 
priaitives  heeded  for  problem  solving.  8e  do  not  believe  that 
computers  will  be  able  to  prove  deep  mathematical  theorems  without  the 
use  of  a  powerful  control  structure.  Nor  do  we  believe  that  computers 
can  solve  difficult  problems  where  their  domain  dependent  knowledge  is 
limited  to  finite-state  difference  fables  of  connections  between  goals 
and  methods.  Difference  tables  can  be  trivially  simulated  by 
conditional  expressions  in  PLAINER. 
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Difficult  problews  for  PLA8HEB 


Be  would  be  grateful  tc  any  reader  who  could  suggest  types  of  problems 
which  sight  be  difficult  to  encompass  naturally  within  the  present 
formalism.  PLANNEB  is  intended  to  be  a  good  language  for  the 
creation  and  description  of  problem  solving  strategies.  Currently  it 
operates  within  the  restriction  of  generalized  stack  discipline.  By 
relaxing  this  restriction  we  could  make  the  language  completely 
rest artable  at  the  considerable  cost  in  efficiency  of  having  to 
garbage  collect  the  stack. 

Speed:  PLANNEB  runs  best  on  a  fast. general  purpose  computer. 

However  two  special  kinds  of  hardware  would  be  useful.  Alan  Kay  has 
pointed  out  that  special  hash  code  hardware  could  make  the  functions 
GET  and  POT  as  fast  for  nodes  as  index iag  hardware  docs  for  vectors. 
Second  if  we  had  a  load  thru  wask  instruction,  then  we  could  speed  up 
Monitoring.  The  instruction  would  interrupt  if  the  appropriate 
monitor  bits  were  on.  Both  of  the  above  kinds  of  instructions  should 
probably  be  micro-coded. 

Bemory:  There  is  never  enough  fast  random  access  storage. 
Furthermore  the  eighteen  bit  address  space  of  the  FDP-10  is 
inadequate.  Be  need  a  bigger  address  space  for  the  following 


purposes: 
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Garbage  collection 

Breathing  space  between  data  spaces  [especially 

stacks  ] 


Backtracking 
Dynaaic  linking 

Exploding  definitions:  We  cannot  afford  to  replace  every  ter* 
by  its  definition  in  trying  tc  prove  theoreas.  However,  in  the  proof 
of  alaost  every  theorea  it  is  necessary  to  replace  some  terns  by  their 
definitions.  Domain  dependent  methods  aust  be  developed  to  make  the 
decision  in  each  case. 

Creating  PLAHNEH  theoreas:  We  need  to  determine  when  it  is 
desireable  to  construct  PLANREH  theore»s  as  opposed  to  dynaaically 
linking  the*  together  at  run  ti«e.**At  the  present  we  have  only  a  few 
exaaples  of  nontrivial  constructed  theoreas.  We  can  generate  some 
froa  the  functional  abstraction  of  protocols  and  frca  atteapts  to 
construct  scheaatic  prcofs  of  theoreas.  Others  are  generated  as  the 
answers  to  simple  probleis.  For  exaaple  if  we  ask  the  computer  how  it 
would  put  all  the  saall  green  and  yellow  bricks  in  the  red  box,  then 
it  might  answer: 


<for  [[<face>  facel  face2  ]  [<brick>  brickl] 

[[“•"current"  [  saall-brick  Jbrickj]  ] 
<current  [face  _face1  .brick ]> 

<current  [color  «face1  green  ]> 

<current  [face  _face2  .brick  ]> 

<current  [color  *fac«2  yellow ]> 

<pi-  -up  .brick> 

<carrj-to  [above  [red  fcox]J> 

<drop>> 
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Terry  Winograd  has  developed  a  program  to  translate  English  into 
PLANNEH  theorems.  An  interesting  expreriment  that  could  be  attempted 
mould  be  to  modify  a  chess  porgram  so  that  it  mould  return  a  PLANMEB 
program  as  mell  as  the  symbolic  description  of  a  position.  The  idea 
is  that  the  PLANNEE  program  mould  represent  the  plan  of  action  that 
mould  be  taken  in  case  of  the  various  moves  that  the  opponent  mignt 
take.  Billian  Henneman  has  investigated  some  of  the  possibilites  for 
doing  planning  in  king  and  pamn  end  games.  The  problem  seems  to  be 
very  difficult  but  not  impossible  given  the  present  state  of  the  art- 

Arbitrary  Constraints:  Using  procedures  as  a  semantic  base 
requires  us  to  solve  the  problem  of  making  procedural  formalisms  more 
goal-oriented.  The  guantif icational  calculus  is  very  goal  orieuted 
but  suffers  groming  pains  trying  to  introduce  procedural  knomledje. 

Manipulation  of  PLANNEE  theorems:  PLANNEE  provides  a  flexible 
computational  base  for  manipulating  theorems  that  can  be  put  in 
disjunctive  normal  form.  Tie  need  to  deepen  our  understanding  so  that 
me  can  carry  out  similar  manipulations  on  PLANNE8  theorems  mith  the 
same  facility. 

Progressive  refinement:  Be  need  to  make  mare  use  of  the  style 
of  reasoning  in  mhich  me  construct  a  pl?n  tor  the  solution  of  a 
problem  from  necessary  conditions  that  the  solution  most  have,  attempt 
to  execute  the  plan,  find  out  mhv  it  does  not  work,  and  then  try 
again.  The  style  is  often  used  in  chess  mhere  very  much  the  ^ame 
game  tree  is  gone  over  several  times;  each  time  mith  a  deeper 
understanding  of  mhat  factors  are  relevant  to  the  solution. 
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Garbage  collection  of  assertions:  Statements  which  have  been 
asserted  should  go  away  automatically  when  they  can  no  longer  be  of 
use.  Unfortunately,  because  cf  some  logical  problems  and  becuause  of 
the  retrieval  system  of  PLANNER,  we  have  difficulty  in  achieving 
completely  automatic  garbage  collection.  The  erase  primitive  of  the 
language  provides  one  way  to  get  rid  of  unwanted  statements.  If  the 
asserted  statement  appears  in  the  local  state  of  seme  process  instead 
of  in  the  global  data  base  then  it  will  disappear  automatically. 

Simultaneous  goals:  Re  often  find  that  we  need  to  satisfy 
several  goals  simultaneously.  Re  usually  try  to  accomplish  this  by 
choosing  one  of  the  goals  to  try  to  achieve  first.  However,  when 
working  on  the  goal,  we  should  keep  in  mind  the  other  constraints  that 
the  goal  must  satisfy.  One  solution  is  to  pass  the  goal  to  be  worked 
on  as  a  list  whose  first  element  is  the  goal  aad  whose  succeeding 
elements  are  the  other  goals  which  must  be  simultaneously  satisfied. 

Nonconstructive  proofs:  The  most  natural  way  to  do  a  proof  by 
contradiction  is  to  try  to  calculate  in  advance  the  statement  which 
ultimately  will  produce  the  contradiction.  The  method  is  to  find  a 
statement  s  such  that  S  is  provable  and  [not  S]  is  provable.  Bore 
precisely,  we  compute  a  statement  S,  make  S  a  goal,  and  then  make  [not 
S]  a  goal.  Bob  Boyer  has  pointed  out  that  in  mathematics  if  the  goal 
is  tc  prove  S,  then  if  at  any  point  in  the  proof  the  main  goal  redness 
to  the  subgoal  to  prove  [not  s ],  then  a  proof  by  contradiction  emm  be 
completed. 

Hodels  of  Do  maims:  Suppose  that  if  is  model  for  the  set  of 
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hypotheses  H  with  ccnseguent  C.  Using  constructive  logic  a  subgoal  S 
of  the  goal  C  WGuld  be  rejected  if  it  could  be  shown  that  it  was 
unsatisf iable  by  fl.  Often  rejections  are  Bade  on  the  basis  of  a  model. 
For  example  in  the  intuitive  model  of  Zeraelc-Fraenkel  set  theory  all 
the  descending  element  chains  are  finite  and  terminate  in  the  null 
set.  Furthermore  every  set  has  an  ordinal  rank.  Thus  the  ordinals 
form  the  Lack  bone  of  the  set  theory.  The  intuitive  meaning  of  [ ♦  A 
B]  [where  A  and  B  are  ordinals]  is  the  concatenation  of  A  with  B.  The 
intuitive  meaning  of  [*  A  B]  is  the  concatenation  of  A  with  itself  B 
times.  If  two  ordinals  have  the  same  order  type  then  they  are  egual. 
Thus  intuitively  we  would  expect  that  [=  [♦  1  omega]  omega]  is  true. 
Every  well  developed  mathematical  domain  is  built  around  a  complex  of 
intuitive  models  and  simple  examples  and  procedures.  Axiom  sets  are 
constructed  to  attempt  to  rigorously  capture  and  delineate  various 
parts  of  the  complex.  One  of  the  most  important  criteria  for  judging 
the  importance  of  a  theorem  is  the  extent  to  which  it  sheds  light  on 
the  complex  of  the  domain.  These  complexes  uast  be  mechanized.  Be 
conclude  that  it  is  unlikely  that  deep  mathematical  theorems  can  be 
proved  solely  from  axioms  and  definitions  by  a  uniform  proof 
procedure.  A  uniform  proof  procedure  based  on  model  resolution  does 
not  provide  the  means  for  mechanizing  the  complex  of  a  dcmain.  Hodel 
resolution  is  a  strategy  for  deciding  which  clauses  to  resolve.  There 
is  a  great  deal  more  tc  mechanizing  the  complex  of  a  domain  than 
simply  pruning  proof  trees.  Furthermore,  clauses  are  often  false  in  a 
model  even  though  they  ace  irrelevant  to  the  proof  that  is  being 
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sought.  One  vay  that  is  often  used  to  try  to  find  a  counterexaaple 
to  a  false  statement  about  ordinals  is  to  atteapt  to  construct  the 
counterexaaple  froa  well  knovn  ordinals.  Soae  veil  knovn  ordinals  are 
1,  2,  3,  oaega,  the  least  uncountable  ordinal,  etc.  Thus  in  seeking  a 
counter  exaaple  to  the  stateaent  that  there  are  only  finitely  aany 
Unit  ordinals  less  than  a  given  ordinal  ve  need  go  no  further  than  t  * 
oaega  oaega]. 
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7.  Models  of  Procedures  and  the  Teaching  of  Procedures 


7.1  Models  of  Procedures 


7.1.1  Models  of  Expressions:  Intentions  in  ISTEKDEH 

A  pro b lei  solver  needs  to  have  sole  way  to  knew  the  properties 
of  the  procedures  which  it  uses  to  solve  probleas.  It  can  use  th*> 
knowledge  which  it  has  as  a  partial  nodel  of  itself.  In  order  to  be 
able  to  aodel  procedures*  it  seeds: 

1:  a  way  to  express  properties  cf  procedures. 

2:  i  way  to  establish  that  the  properties  do  in  fact  hold  for 
the  procedures. 

IMTEMDBB  is  a  goal-oriented  foraalisa  for  expressiong  aodels 
of  procedures.  The  aodels  are  expressed  in  teras  of  intentions  of 
what  the  procedure  should  accomplish.  The  priai'cives  of  IRTEVPE8  are 
concerned  with  expressing  intentions  in  procedural  terns.  Thus  the 
intentions  are  capable  of  theaselves  hawinq  intentions.  IHTERDSP 
aechanizes  the  knowledge  needed  to  do  execution  induction  on 
procedures.  It  calls  on  PLAIREB  to  satisfy  goals  and  uses  PLAIREB 
theoreas  to  hold  the  substantiae  knowledge  (sucl  as  facts  about 
integers)  which  are  needed  to  prowe  properties  of  procedures. 
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INTENDER  has  three  main  uses  for  PLANNEE: 

1:  It  enables  PLANNER  to  verify  that  its  procedures 

do  what  is  intended. 

2:  Most  knowledge  in  ELANNER  is  embedded  in 

procedures.  INTENDER  helps  PLANNER  understand  these 
procedures  and  thus  to  have  some  knowledge  of  its  own 
problem  solving  behaviour. 

3:  IN1ENDKE  enables  PLANNER  to  verify  that  its  plans 

(procedures)  are  valid  relative  to  its  procedural 

model  cf  the  world. 

We  shall  express  the  properties  of  an  expression  x  by  the 
following  function. 

<1 NTENT 

[-declarations-]  1  predecessor J  JxJ  |function|  - 
successors->  is  tr>ie  if  ipredecessor |  evaluates  to  true,  the  function 
applied  to  the  value  of  JxJ  is  true,  and  the  -successors-  all  evaluate 
to  true.  The  value  of  the  function  intent  is  the  value  of  Jx|.  The 
function  intent  is  used  to  state  a  model  for  an  expression  x.  As  might 
be  expected  the  models  ace  stated  in  PLANNER.  The  intentions  are 
established  by  INTENDER  which  is  the  language  in  which  intentions  are 
stated.  The  proof  is  by  induction  on  the  activations  of  the 
procedure.  Thus  for  the  control  structure  of  LISP,  the  proof  is  by 
recursion  induction.  To  avoid  confusion  we  shall  write  the  intention 
variables  in  upper  case.  Also  we  shall  use  ! '  to  suppress 
invocations.  Thus  <♦  2  3>  evaluates  to  the  number  5  while  !’<+  2  3> 
evaluates  to  <♦  2  3>.  For  example  the  intentions  in  the  prog  below 


are  all  true. 


7.1  page  293 


<prog  foo  [[a  1]  [b  2]] 

!;<intent  []  <goal  !•<=  1  .a>» 

;"Yes  the  identifier  a  was 

indeed  initialized  to  1.  Hill  wonders  never  cease?" 

! ;  <intent  []  <goal  !*<=  .b  !•<*  .a  1»» 

!  ;<intent  [  ] 

<goal  !  *  <=  .b  2>> 

<_  :b  <♦  .b  1>> 

<function  [XI  <goal  !‘<=  .X  3»> 

<goal  I '<- .b  3>>> 

;"He  have  just  verified  that  an  assignment  statement 

can  change  the  value  of  the  identifier  b  from  2  to  3" 
<.foo  .b> 

;"exit  .foo  with  .b"> 

The  following  protoccl  for  1 NTENDEH  verifies  that  the 
intentions  in  the  above  program  do  in  fact  hold.  He  shall  use  the 
notation  J identifier J n j  for  the  JnJth  value  of  [identifier J  and 
Jidenifier|_  for  the  initial  value. 


.  .  .  <assert  !*<=  1  a_»  .  .... 

<assert  !*<*  2  b_>> 

<goal  !*<=  1  a  >> 

<qoal  !•<=  b_  !•<♦  a_  1»> 

<goal  !•<=  2  b_» 

<assert  !*<=  b  1  <♦  b  1»> 

<goal  !«<=  <♦  h_  1>  3>> 

<goal  !'<=  b_  1  3» 

The  essential  idea  for  intentions  comes  frcm  the  break 
function  introduced  into  LISE  by  W .  Martin,  iu  intention  is  not 
allowed  to  assign  a  value  to  a  non-intention  identifier  and  ordinary 
code  is  not  allowed  to  reference  intention  identifiers.  He  shall 
distinguish  intention  identifiers  from  ordinary  identifiers  by  putting 
them  in  all  caps.  The  intention 
<IHTEH  D 


[-declarations- J  J predecessor l  [expression; 


|function|>  is  exactly  like  the  function  intent  except  that  intention 
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variables  can  be  declared  in  the  declaration.  In  addition  we  need  a 
function 

COVEHALl 

[-declarations- J  J predecessor]  {expression] 
ction|>  which  is  exactly  like  the  function  IHTE8D  except  that  it 
is  used  to  state  the  overall  intention  of  a  procedure.  If 
| expression]  is  a  junction  then  the  overall  input  output  intentions  of 
the  junction  are  given  by  ] predecessor }  and  ] function].  Thus  INT2NDEH 
does  computational  induction  across  process  boundaries.  All  the 
intentions  in  the  function  fact  are  true  where 


<define  fact  <functiot  fact  [n] 

<overall  [  ] 

<intention  [ ] 

<goal  !*<i.s?  !  *<non-neg>  .n>>  •  '  '  ' 

<assert  ! '<is?  !'<non-neg>  .  n»> 

<repeat  £[teap  1]  £i  0]] 

I ; <inte Jtion  [  ] 

<prog  [  ] 

<goal  !*<is?  !'<non-neg>  ,i>> 

<goal  !'<=  .temp  !  *<factorial  ,i>>» 
<prog  [  ] 

<assert  !*<is?  !'<non-neg>  . i>> 
<assert  !%<=  .temp  <facxorial  ..i»>» 

<cond 

[ <is?  .n  .  i> 

<.fact  .tempi 

;"exit  .fact  with  .  temp"]> 

<_  :i  <♦  .i  1» 

<_  :tesp  <*  .i  ,te»p»> 

<fuuction  [X] 

<intentioa  [  ] 

<assert  !*<=  .X  !'<factorial  n»> 
<goal  !«<=  .X  ! '  <factorial  .n»»»» 


where 


<define  factorial  <f unction  [nl 
<overall  [ ] 

<intention  [ ] 
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<goai  !*<is?  !*<non-neg>  .  n>> 

<assert  ! *<is?  !f<non-neg>  ,n>>> 

<cond 

[<is?  C  .n> 

1] 

[-•"else" 

<*  .n  <fac.torial  <-  .n  !>>>]> 

<f nnct ion  [ X  ] 

<intention  [  ] 

<prog  [  ] 

<cond 

[6<goal  l*<-  .n  0>> 

<assert  ! * <=  .X  1>>] 

[<goal  !e<not  !  •  <=  .  n  0>» 

<assert 
!  *<= 

.  X 

!  *  <*  .n  !  *<fact  !•<-  .n  1»»>  ]> 
<assert  !«<=  .X  !  *  Combinations  .n  0>>> 

<assert  !•<=  .X  !’<fact  .n>>>> 

<prog  [ ] 

<cond 

[€<goal  !*<=  .n  0>> 

<goal  !•<=  .X  1»] 

[  6<goal  !’<not  !•<=  .n  0»> 

<goal  !'<=  .X  !*<*  .n  !*<fact  !*<-  .n  1»»>]> 
<goal  !'<=  .X  !*  Combinations  .n  0>» 

<goal  !•<=  .X  !*<fact  .n»>»»» 


The  following  is  a  protocol  of  the  action  of  INTENDER  on  the 
intentions  of  fact: 


<assert  ! *<is?  !'<non-neg>  n_>> 
enter  intentions  of  repeat 

Case  1:  initial  entry 
<assert  !•<=  1  teap_>> 

<assert  !*<=  0  i_>> 

<goal  !'<is?  !'<qon-neg>  i_>> 

<goal  !*<=  1  !'<factorial  0»> 

enter  intentions  of  factorial 
n  becoaes  0 
X  beccaos  1 

<goal  !’<is?  !'<non-neg>  “\» 
<goal  !*<=  1  1>> 

<assert  ! * <=  1  !*<factorial  0>>> 
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Case  2:  inductively  assuae 
<assert  !*<is?  !*<non-neg>  i_>> 

<assert  !*<=  temp_  ! 1 <factorial  i_>>> 
enter  conditional 

Case  1: 

<assert  !’<=  n_  i_>> 

<goal  !’<=  tesp_  !  ^factorial  n_>>> 

Case2; 

<assert  !’<not  !*<=  n_  i_>>> 

<assert  I  * <-  i_1  I’<+  i_  1>>> 

<assert  !*<= 

temp  1 

!»<*“i_1  temp_>» 

<goal  !  •  <=  temp_1  !*<factorial  i_1»> 
enter  intentions  of  factorial 
n  becomes  i_1 
X  becones  temp_1 
<goal  !‘<is?  !’<non-neg>  i  1>> 

<gcal  !*<=  0  i_1» 

FAIL 

<gcal  !»<= 

!«<* 

i  1 

!  ’  <f  actorial  !•<-  i_1  1»> 
tenp_1» 

On  the  other  hand  if  INTENDER  analyzes  the  intentions  of 
factorial  ve  get; 


<assert  !’<is?  !*<non-neg>  n_>> 
enter  conditional 


Case  1 : 

<assert  !*<=  0  n  >> 

<qoal  !*<=  1~! * <f act  C>>> 
enter  intentions  of  fact 
n  beccnes  0 


X  becones  1 
<goal  ! * <=  0  0>> 
<goal  !*<=  1  1» 


€  2  * 

<assert  !’<not  !*<*  0  n_>>> 

<assert  !•<= 

M<factorial  !*<-  n  1» 
J  *  <f  act  !•<-  n  1»>> 
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<goal  !’<  = 

!»<* 

n_ 

!'<factorial  !'<-  n_  1>> 

! !  <f  act  n_»>> 
enter  intentions  of  fact 
n  beccaes  n_ 

X  becones 

!  *<* 

n_ 

!7<factorial  !’<-  n_  1>» 

<goal  !'<= 

!•<* 

D 

!T<factorial  !*<-  n_  1»> 

!  •  Ccoabinations  n_  C»'> 

<goal  ! * <- 

!  »<* 

n_ 

I’Cfactoriai  ’•<-  n_  1>» 

!  *<* 

n 

!7<fact  !«<-  n_  1»»> 

The  intentions  for  the  function  fctrl.  defined  below  are  not  so 
easy  to  establish. 


<define  fctrl  <function  fctrl  [n] 

Cor;  tall  [[AEG  «n]J 
^intention  [  ] 

<goal  ! '<is?  !’<non-neg>  .n>> 

<assert  !*<is?  !*<non-neg>  .n>» 

<repeat  [[teap  1]] 

!;<intention  [] 

<goal  !•<=  .te*p  !  'Ccoabinations  .ABG  ,n»> 
<assert  !*<=  .teap  ! ’Ccoabinations  .ABG  .n»» 

<cond 

[<is?  0  .n> 

<.  fctrl  . teap> 

;"exit  .fctrl  with  .  teap"]> 

<  :teap  <*  .teap  .n» 

<“  :n  <-  .n  1»> 

<f unction  [X] 

Cintention  [  ] 

Cassert  !•<*  .2  I’Cfactorial  ,ABG>» 

<goal  !*<=  .X  1  •  <f actorial  .ABG»»»» 
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We  need  to  define  an  auxiliary  function  in  order  to  do  the  proof: 

<defme  coabinations  <f  unction  [n  r  1 
<overall  [  ] 

<intention 

<and 

S<goal  !'<is?  !'<non-neg>  .n>> 

6<goal  l*<is?  !*<non-neg>  ,r>> 

6<goal  !*<is?  !’<greater=  .r>  .n>>> 

<asd 

S<assert  !*<i s'i  !*<non-neg>  .n» 

5<assert  !  *<rs?  !*<non-neg>  .  r» 

&<assert  !'<is?  !'<greater=  .r>  .n>»> 

<cond 

[<is?  .n  .t> 

1] 

[-»MexseM 

<*  .n  <ccnbina tions  <-  .n  1>  .r>>]> 

<f unction  [X] 

<intention  [  ] 

<prog  [  ] 

<cond 

[ 6<goal  !'<=  .n  .r» 

<assert  !'<=  1  -,X>>] 

[S<goal  S'<=  .r  0» 

<assert  !•<=  .X  !  *  ^.factorial  .  n>»]> 

<assert 
!  »<= 

.X 

!  '  <* 

I 'Ccoabina tions  !*<-  .n  1>  .r> 
•  n»» 

<prog  f  ] 

<cond 

[5<goal  !•<=  .n  «r» 

<goal  l 1  <*  1  .X»] 

[<goal  !*<=  .r  0» 

<goal  !*<=  .X  !'<factorial  .  n»>]> 

<goai 

!  •<* 

.X 

J'<* 

!  ^combinations  S*<-  .n  1>  »r> 
,n»»>»>> 

IhTENDEB  yields  the  following  protocol  for  the  intentions  of 


fetr 1: 
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<assert  !'<is?  ! '  <ncn-iteg>  n  >> 
enter  intentions  of  repeat  ~ 

Case  1:  initial  entry 

<assert  !'<=  1  temp_>> 

<goal  !’<=  1  ’^combinations  n_  n_»> 
enter  intentions  of  combinations 
n  becomes  n_ 
r  becomes  n_ 

<goal  !'<is?  !*<non-neg>  n_» 

<goc.l  !'<is?  !’<non-neg>  n_» 

<goal  !*<is?  !'<greater=  n_>  n_>> 
<goal  ! ' <=  n_  n  » 

<goal  !•<=  1  1>> 

f'ase  2:  inductively  assume 
<assert 
!•<= 

temp_ 

!  *  <combinations  n_  n_>» 
enter  conditional 

Casel: 

<assert  !*<=  0  n_1» 

<goal  !'<=  temp_  ! *<factorial  n_>>> 
enter  intentions  of  factorial 
n  becomes  n_ 

X  becomes  temp_ 

<gcal 

!  •<= 

temp_ 

!  *  Combinations  n_ 


C ci S 6  2* 

<assert  !'<not  !'<=  0  n_1>>> 

<assert 

**  *  !  •  <- . 

te»p_1 

jc<*”temp_  p._1»> 
<assert  ! * <=  n_2  !•<-  n  1  1>  >> 

<goal  !•<= 

teap_1 

’^combinations  n_  u_2»> 
enter  intertiens  of  combinations 
n  becomes  n_ 
r  becomes  n_2 
X  becomes  tenp_1 
<goal  !*<is?  !*<non-neg>  n_» 
<goal  !’<is?  !’<non-neg>  n_2>> 


0>>> 
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<goal  !'<is?  !'<greater=  c_2>  n_>> 

<gcal  ! ’ <- 

temp  1 
!  *  <* 

! ' <ccnbinations 
n_ 

n_1> 

n_1>» 

He  can  use  the  same  techniques  for  showing  that  a  procedure 
will  converge  if  its  arguments  satisfy  certain  conditions.  The  idea 
is  tc  define  a  partial  order  with  no  infinite  descending  chains  and 
then  prove  that  every  time  control  goes  through  the  same  point  in  the 
program  that  it  has  descended  in  the  partial  order.  The  ordering  we 
shall  use  is  that  [ S HAILES  [ |a |  |bj  |c|]  [|d|  je|  |fl]]  is  true  if  one 
of  the  following  three  conditions  holds: 

! a  1  is  less  than  Jd| 

la  |= |e 1  and  jbj  is  less  than  je| 

|asj=|e|  and  ihj=|e|  and  Jc|  is  less  than  *f|  For  example 
consider  Ackerman's  function  as  defined  below: 


<define  ackeraan  < function  [z  x  y 
<overall  [  ] 

Cintention  [  J 
<prog  [  ] 

<goal  !'<is?  !'<.aon-neg>  .z>> 
<goal  2 '<is?  !'<non-neg>  .x>> 
<goal  !'<is?  !*<..on-neg>  .y>» 

<prog  [ ] 

<assert  ! - < is ?  !'<non-neg>  »z>> 
<assert  !'<is?  !*<non-neg>  .x>> 
<asser?  !*<is?  !,<non-neg>  ,y>>> 

saaller> 

<cond 

[<is?  0  .x> 

<rule  [  ]  .z 

[0  •  ?  3 
[1  03 

£<greater  1>  1  j>  3 
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[<is?  0  .z> 

<♦ 

<ackeraan  0  <-  .x  1>  .  y> 
1>] 

[  ->Melse" 

<ackernan 

<-  .z  1> 

<ackernian  .z  <-  .x  1>  .y> 

•  y>3> 

<f unction  [k] 

<intention  [  J 

<assert  !'<is?  !*<non-neg>  .«>> 
<goal  !'<is?  !'<non-neg>  .*>>»»> 


<define  show-saaller  <conseguent  [a  b  c  d  e  f] 

[smaller  [ ?a  ?b  ?c]  [?o  ?e  ?f]J 
<cond 

[f<goal  !'<is?  !*<less  ?d>  ?a»] 

(G<goal  !•<=  ?a  ?d» 

<cond 

[6<goal  I  *<is?  !  *<less  ?e>  ?b»] 
[G<goal  !*<=  ?b  ?e» 

<gual  !  *<is?  !*<less  ?f>  ?c»  ] 
[  -*’*elser  <fail>]>  J 

[^"else"  <f ail>  ]»> 

The  protocol  for  PLANNER  on  ackeraan,s  function  is: 

<assert  !*<is?  !*<non-neg>  z_» 

<assert  !'<is?  !'<non-neg>  x_» 

<assert  !*<is?  !*<non-neg>  y_>> 
enter  conditional 

Case  1 : 

<assert  !  =  0  x_>> 

<assert  !*<is?  !'<greater  0>  x_>> 

pacp  *)  * 

<assert  I ' <=  0  z_>> 

<goal  [saalie: 

[  0  ! *<-  x  1>  y  ] 

£0x_y_]> 
enter  shov-saaller 
a  becoaes  0 
b  becoaes  !*<-  x_  1> 
c  becoaes  y_ 
d  Lecoaes  0 
e  .becoaes  x 


f  becomes  y 

<goal  !~<aS  !  * <less  0>  0» 

FAIL 

<goal  !'<=  0  0>> 

<gcal  !  *  <less  x_>  !'<-  x_  1» 

<assert  !*<is?  !*<greater  0>  z>> 

Ca“e<goal  [smaller 

[z  !  •<-  x  1>  y  ] 

C*I  *-  Y_  f]> 

<goal  [saaller 

[!*<-  z  1>  <ackeraan  z  ! •<-  x  1>  y_>  y  >] 

[z_  *_  T_]]> 

ie  would  like  to  show  that  if  we  reverse  a  list  twice  then  we 
get  the  original  list. 


<define  reverse  <f unction  rev  [1] 

<overall  [] 
t 

<repeat  [[u  .1 ]  [v  (}]] 

! ; <intention  [  ] 

<goal  !*<is?_..v  !,<reverse  !?<sub  J  .u»» 
<assert  !*<is?  .v  !*<^everse  !*<sub  .1  ,u»>» 

<cond 

[<eapty?  .u> 

C.rev  -v> 

;"exit  .rev  with  .  v"]> 

<_  :v  (<1  .u>  !.v)  > 

<_  :  u  <rest  ,u»> 

<f unction  [X] 

<intention  [ ] 

<and 

<cond  * 

[  <is?  ()  .1> 

<assert  !  •<=  .X  ()»]> 

<assert  !*<is?  .1  l*<rev  .  1»> 

<assert  !'<is?  .1  !*<revcrse  .X»>> 

<prog  (  ] 

<cond 

[  <is?  ()  .1> 

S<goal  :*<=  .X  {)»]> 

S<goal  !'<is?  .X  !*<rev  .1»> 

S<goal  i'Cis?  .1  !*<reverse  .X»»»>» 
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He  would  like  to  show  that  for  all  |1|  that  <reverse  <reverse  |1|»  is 
|1|.  Again  we  will  need  a  helping  function  to  express  our  intentions. 
He  stall  define  <SUB  jxj  | y 1 >  to  be  ]xj  subtract  jyl  as  lists. 

<define  last  <function  [x] 

<cond 

[Cenpty?  <rest  .x>> 

<1  • x>  1 
[  -."else" 

<last  <rest  .  x>>]>» 

<define  butlast  <f unction  [x] 

<cond 

[Cenpty?  <rest  .x>> 

0  ] 

[-."else" 

{<1  ,x>  <butlast  <rest  ,x>>]>>> 

<define  sub  <f unction  £x  yl 
<overall  [  ] 
t 

<cond 

[<is?  .x  .y> 

0  ] 

[-."else" 

(<1  ,x>  (sub  <rest  .  *>}  .y)  ]> 

<f  unction  [ Z  ] 

<intenticn  [  J 
<cond 

[SCgoal  !*<is?  ,y  ()  » 

<assert  !*<is?  ,Z  ,x>>] 

[  6<goal  !  •  <not  ! *<is?  .y  0  »> 

<assert  !*<= 

I* Clast  !'<sub  .x  ! ‘Crest  .y>» 

!  *  < 1  . y>>> 

<assert  !*<= 

.Z 

!*<butlast  !‘Csub  .x  !  *  <rest  .  y>»»  ]> 

<cond 

[SCgoal  !*Cis?  .y  () » 

<goal  !  •  <is?  .Z  .x»] 

[SCgoal  I’Cnot  !*<is?  .y  ()  »> 

<goal  !'<= 

!' Clast  1‘Csub  ,x  ! '•  <rest  ,y>» 

I  *  <  1  .  y>» 

<goal  !’<= 

.Z 

!'<butlast  !*Csub  .x  !• Crest 


y  »>»]»»» 


/ 
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<define  rev  <f unction  [list] 

<overall  [  ] 
t 

Ccond 

[<monad?  .list> 

. list  ] 

[  -."else" 

(<last  . list>  (rev  <butlast  .lisfc>})  ]> 

<f unction  [ X  ] 

<intention  [  J 
<prog  [  ] 

<assert  !*<is?  .X  !’<reverse  .list»> 
<assert  !'<is?  .list  !'<re verse  .X»» 

<prog  [  ] 

<goal  !’<is?  .X  ! *<re verse  ,list>» 

<goal  !'<is?  .list  !’<reverse  ,X»»>»» 

The  protocol  of  INTENDER  on  REVERSE  is: 
enter  intentions  of  repeat 

Case  1 :  initial  entry 
<assert  !*<=  u_  1_>> 

<assert  !•<=  v_  () » 

<goal  !*<is?  ()  !*<reverse  !  *<sub  1_  1_»» 
enter  intentions  of  sob 
x  becones  () 
y  becones  {) 

<assert  !’<=  ()  J'osub  1_  1_>>> 
enter  intentions  of  reverse 
1  becones  {) 

<assert  !*<=  {)  !'<reverse  ()  »> 

Case  2:  inductive  hypothesis 
•cassert  !'<is  v_  !'<reverse  !*<sub  1_  u_>>» 
enter  conditional 

pa  cp  1  • 

<assert  !'<=  ()  u_» 

enter  overall  consequent.  -  * 

X  becones  v_ 

<goal  !*<is  v_  l^reverse  1_>» 
<assert  !'<not  1  *  <=  {/  u_»> 

Cst s€  2* 

<assert  !*<=  v_  1  ( !  •  <  1  u_>  !•  (value  v} )  » 
<assert  !*<=  u_1  !*<rest  u_»> 

<goal  !'<is 

( 

1  • <1  u  > 
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!•  {reverse  !*<sub  1_  u_>}) 

! '<reverse 
! • <sub 

1_ 

! '  <rest  u_»»> 

Allowing  shared  side  effects  in  structured  data  considerably 
complicates  the  process  of  proving  intentions. 

7.1.2  Models  in  Patterns:  Alas 

Aias  are  like  intentions  except  that  they  are  actors  and  occur 
in  patterns. 

<AIM  predecessor  pattern  down  up  successors>  is  the  form  for  a 
call  to  the  actor  aia.  An  ain  will  be  said  to  be  attained  when  the 
following  conditions  are  satisfied: 

[1]  Its  predecessor  evaluates  to  true 

[2]  We  apply  the  function  down  with  two  arguments.  The  first 
is  the  expression  to  be  matched.  The  second  is  <>  if  and  only  if 
pattern  doesn't  match. 

[3]  We  apply  the  function  up  with  two  arguments.  The  first 
is  <>  if  and  only  if  the  rest  of  the  pattern  doesn't  match.  The 
second  is  <>  if  and  only  if  pattern  fails. 

.[J*-]  The  successors  evaluate  to  true. 

The  function  down  expresses  the  intent  of  the  downward  action  of  the 
pattern  and  the  function  up  expresses  tfca  upward  gcing  action.  The 
actor  <AXMIHG  [declarations]  predecessor  pattern  down  up  successors> 
xs  exactly  like  the  actor  AIM  except  that  intention  variables  may  be 
declared.  For  example  the  aim  in  the  folowing  expression  is 
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attained: 


<aining  ^[OLD-F  .f]] 

_f 

<function  [X  Y] 

<assert  !*<eg  .f  .X>> 

<assert  !’<is?  .X  t>>> 

<function  [X  Y] 

<cond 

[6<goal  !  •  <is?  .X  <»> 

<assert  !’<eg  .f  .OLD-F» 

<assert  !*<is?  .X  []>>] 

[&<goal  ! * <is?  .X  t>> 

<assert  !*<eg  .f  .X>> 

<assert  *  t»]»> 

The  value  of  f  changes  only  if  the  rest  of  the  natch  succeeds.  The 
actor  <ENT1RE  [declarations]  predecessor  pattern  down  up  successors> 
is  exactly  like  the  actor  AIRING  except  that  it  is  used  to  express  the 
entire  intent  of  the  pattern.  For  exanple  for  the  actor  ATOMIC  which 
takes  no  arguments  and  Batches  only  atoas  can  be  characterized  b/r 


<define  atonic  <actor  [  ] 

<entire  ^] 

<atonic> 

<function  [X  Y] 

<cond 

[6<goal  l’<atoa  .X>> 

" '  <hssert'  !*<is?  .Y  t>>] 

[ 6<goal  !  *  <not  !*<atoi  .X»> 

< assert  !'<is?  .Y  <>>>]» 

<f unction  [X  Y ] 

<assert  l*<is?  .1  .Y»>>>> 


7.1.3  Models  of  PLANNEE  Theoreas 
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We  shall  construct  models  for  E1ANNEE  theorems  in  auch  the 

same  manner  as  for  MATCHLESS  patterns. 

CTHINTENT  predecessor  x  down  up  successors>  is  true  if  the 
following  conditions  are  met: 

[1]  the  predecessor  is  true. 

[2]  We  apply  the  function  down  with  two  arguments:  The  first 
argument  is  <>  if  and  cniy  if  the  evaluation  of  x  fails.  If  th*-  first 
argument  is  not  <>  then  the  value  of  the  second  argument  is  the  value 
of  x. 

[3]  We  apply  the  function  up  with  four  arguments.  The  first 
is  <>  if  and  only  if  the  rest  of  the  computation  fails.  If  the  first 
argument  is  <>  then  the  second  argument  is  the  message  of  the  failure. 
The  third  argument  is  <>  if  and  only  if  the  evaluation  of  x  fails.  If 
the  third  argument  is  not  <>  then  the  fourth  argument  is  the  value  of 
x. 

The  function  THINTENC  is  exactly  like  the  function  THINTENT 
except  that  a  declaration  of  intention  variables  must  be  the  first 
argument.  For  example  the  folliwng  intention  is  always  satisfied: 
Becall  that  the  function  ASS  EFT  1  will  assert  a  statement  if  has  not 
already  been  proved. 

.  ,  *  m\  •  .  -  *  -  -  ♦  •  •  •  ' 

<thintend  [[already-proved  <>]] 

<assert1  [subset  a  b ]> 

<f unction  [XI] 

<cond 

[S<goal  [proved  [subset  a  b]]> 

<assert  !*<is?  .X  <>>> 

<_  : already-proved  t> 
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<assert  !'<is?  .Y  <>»  ] 

[ 6<goal  !*<not  [proved  [subset  a  b]]» 

<assert  [proved  [subset  a  b]]> 

<assert  !'<is?  .X  t» 

<assert  !»<is?  .1  [subset  a  b  ]» ]» 

<f unction  [X  Y  0  V] 

Ccond 

[<is?  already-proved> 

<cond 

[6<goal  !«<is?  .X  <>» 

<erase  [proved  [subset  a  b  ]]>]>]> 
<assert  !*<is?  .0  .X» 

<assert  ! » <is?  .7  .Y»» 
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7.2  Teaching  Procedures 


Crucial  to  our  understanding  of  the  phenomenon  of  teaching  is 
the  teaching  of  procedures.  Understanding  the  teaching  cf  procedures 
is  crucial  because  of  the  central  role  played  by  the  structrual 
analysis  of  procedures  in  the  foundations  of  problem  solving.  How  can 
procedures  such  as  multiplication,  algebraic  simplification,  and 
verbal  analogy  problem  solving  be  taught  efficiently?  Cnee  these 
procedures  have  been  taught,  how  can  most  effective  use  of  them  be 
made  to  teach  other  procedures?  In  addition  to  being  incorporated 
directly  as  a  black  box,  a  procedure  which  has  already  been  taught  can 
be  used  as  a  model  for  teaching  other  procedures  with  an  analogous 
structure.  One  of  the  most  important  methods  of  teaching  procedures 

is  telling.  For  example  one  can  be  told  the  algorithm  for  doing 
symbolic  integration.  Telling  should  be  done  in  a  high  level  goal- 
oriented  language.  PLANNER  goes  a  certain  distance  toward  raising  the 
level  of  the  language  in  which  we  can  express  a  procedure  to  a 
computer.  The  language  has  primitives  which  implement  fundamental 
problem  solving  abilities.  Teaching  procedures  is  intimately  tied  to 
what  superficially  appears  to  be  the  special  case  of  teaching 
procedures  which  write  procedures.  The  process  of  teaching  a 
procedure  should  not  be  confused  with  the  process  of  trying  to  get 
the  one  being  taught  to  guess  what  some  black  box  procedure  really 
does  [ as  is  the  case  in  in  seguence  extrapolation  for  example].  The 
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teacher  is  duty  bound  to  tell  anything  that  light  help  the  one  being 
taught  to  understand  the  properties  and  structure  of  the  procedure. 

We  assume  that  the  teacher  has  a  good  model  of  how  the  student,  thinks. 
Also,  just  because  we  speak  of  "teaching*1,  we  do  not  thereby  assuae 
that  anything  like  what  classically  has  been  called  learning  is  taking 
place  in  the  student.  However,  this  dees  not  exclude  the  possiblity 
that  the  easiest  way  tc  teach  aany  procedures  is  through  examples.  We 
can  give  protocols  of  the  action  of  the  procedure  for  various  inputs 
and  enviroaents.  By  "variablization"  [the  introduction  of  identifiers 
for  the  constants  of  the  examples]  the  protocols  can  be  formed  into  a 
tree.  Then  a  recursive  procedure  can  be  generated  by  identifying 
indistinguishable  nodes  on  the  tree.  We  call  the  above  procedure  for 
constructing  procedures  frem  examples  the  procedural  abstraction  of 
protocols.  ..  ocedaral  abstraction  can  be  used  to  teach  oneself  a 
procedure. 

7.2.2  By  Procedural  Abstraction 

7.2. 2.4  Examples  of  Procedural  Abstraction 

7.2.  2.4.  1  Building  a  Call 

We  shall  explain  procedural  abstraction  in  more  detail  using 
the  example  of  building  a  wall.  We  define  <brick-at  |wj  |h|>  to  mean 
that  there  is  a  brick  at  the  location  with  width  |w|  and  height  |h| 


1. <2- 


i\C  fi 


BUILDING  WALLS 


[WALL  I  2] 


(<#>.!) 

(1,1) 

(<#>  <#>) 

(!.<#>) 

[WALL  2  I  ] 


note:  the  numbers  in  the  boxes  represent 

THE  COORDINATES  OF  THE  BRICKS. 
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and  define  the  statement  [wall  J  w {  |h|]  to  mean  that  there  is  a  wall 
of  width  w  and  height  h  using  the  definition 


<de£ine  wall  <function  [w  h] 

Conjunction  [[ww  0]] 

[-."inc"  ww  -."by"  1  -."thru"  .w] 

<con junction  [£hh  ,hj] 

[-."dec"  hh  -."by"  1  -."thru"  0] 
<brick-at  .ww  „hh»>>> 

Thus  <wall  1  2>  means 


<and 

<and 

<brick-at  0  2> 

<brick-at  0  1> 

<brick-at  0  0>> 

<and 

<brick-at  1  2> 

<brick-at  1  1> 

<brick-at  1  0>>>. 

Notice  that  the  syntactic  definition  of  a  wall  runs  orthogonal  to  the 
way  in  which  a  wall  has  to  be  constructed.  Thus  we  could  not  use 
purely  syntax  directed  methods  to  construct  walls.  The  predicate 
<ASSiGNED?  var>  is  true  only  if  the  identifier  var  has  been  assigned  a 
value. 


<define  build-tower 
Consequent  build 

[[!=fir  w  h]  [actions  []]] 

[brick-at  ?u  ?h] 

Ccnd 

[<not?  <assigned?  h>> 

<_  .h  0>]> 

<cond 

[<current?  [brick-at  ?w  ?h  ]> 

<. build  {}  > 

;"exit  .build  with  ()  ]> 

[ <is?  .h  0> 

<. build  <!  *<pat-brick-at  ?w  ?h>)>]> 
<_  :  actions  <gcal  [bricl-at  ? w  <-  .h  1>  ]» 
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<goal  [ put-brick-at  ?v  ?h]> 

<goal  [ check-brick-a t  .w  ,h]> 

<assert  [brick-at  .w  .h]> 

C.build  (!. actions  ! *<put-brick-at  .*  .h>)» 

If  we  give  PLANNER  the  task  cf  constructing  a  [wall  1  2],  then  the 
actions  that  will  be  taken  are: 

<put-brick-at  C  0> 

<put-brick-at  C  1> 

<put-brick-at  0  2> 

If  the  goal  is  T wal  2  1]  then  the  actions  are: 

<put-brick-at  C  u> 

<put-brick~at  0  1> 

<put-br ick-at  1  0> 

<put-brick--at  1  1> 


He  shall  use  tte  expression  new  5  to  Bean  that  a  new  identifier  is 
bound  and  initialized  to  5.  He  shall  use  the  expression  <value  9>  to 
uean  a  reference  to  an  identifier  whose  value  is  9;  the  expression 
<?lter  3  7>  means  that  an  identifier  with  value  3  is  altered  to  be  the 
value  7.  Bore  precisely,  the  protocol  for  [wall  1  2 ]  is 


<new  [1  2  ] 

<new  [UNASSIGNED  UNASSIGNEC] 

<_  <alter  UNASSIGNED  C>  0> 

<Is?  <7alue  0>  < value  1»  IS  FALSE 
SO 

<_  <alter  UNASSIGNED  C>  0> 

<is?  < value  0>  <value  2»  IS  FALSE 

<put-brick-at  <val.ue  0>  <value  0>> 

<_  <alter  0  1>  <♦  <value  0>  1>> 

<is?  <value  1>  <value  2>>  IS  FALSE 
SC 

<put-brick-at  <value  0>  <value  1>> 

<_  <alter  1  2>  <*  <Yalue  1>  1>> 

<is?  <value  2>  <value  2»  IS  TRUE 
SO 

<_  <alter  0  1>  <♦  <value  0>  1>> 
<is?  < value  1>  < value  1»  IS  TRUE 
SO 


[  ]» 
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The  protocol  for  [wall  2  1]  is 
<nev  [2  1  ] 

vnev  [UNASSIGNED  UNASSIGNED  ] 

<  <al ter  ONASSIGNED  0>  0> 

<is?  <value  0>  <value  2»  IS  FALSE 
SO 

<_  <alter  UNASSIGNED  0>  0>  <is?  Cvalue  0>  <value  1»  IS  FALSE 
SO 

Cput-brick-at  <value  0>  Cvalue  0>> 

C_  Carter  0  1>  <♦  Cvalue  0>  1>> 

<Is?  < value  1>  Cvalue  1>>  IS  TRUE 
SC 

<_  <alter  0  1>  Cf  <value  0>  1>> 

<is?  Cvalue  1>  <value  2>>  IS  FALSE 
SC 

<_  <alter  1  0>  0> 

<is?  < value  0>  1>IS  FALSE 
SC 

Cput-brick-at  <value  1>  <value  0>> 
C_  <alter  Q  1>  <♦  Cvalue  G>  1» 
Cis?  < value  1>  <value  1»  IS  TRUE 
SC 

< 

<alter  1  2> 

C*  Cvalue  1>  1» 

<is? 

Cvalue  2> 

Cvalue  2»  IS  TRUE 
SO  [  ]» 

The  protocol  for  [wall  2  2  ]  is 
''new  [2  1] 

Cnew  [UNASSIGNED  UNASSIGNSD] 

C_  Calter  UNASSIGNED  0>  0> 

Cis?  Cvalue  C>  Cvalue  2>>  IS  FALSE 
SO 

C_  Calter  UNASSIGNED  0>  0> 

Cis?  Cvalue  0>  Cvalue  2>>  IS  FALSE 
SO 

Cput-brick-at  Cvalue  0>  Cvalue  0>> 

C_  Calter  0  1>  <*  Cvalue  0>  1>> 

Cis?  Cvalue  1>  Cvalue  2>>  IS  FALSE 
SO 

Cput-brick-at  Cvalue  0>  Cvalue  1>> 

C_  Calter  1  2>  C+  Cvalue  1>  1>> 

Cis?  Cvalue  2>  Cvalue  2»  IS  TRUE 
SO 

C_  Calter  0  1>  <*  Cvalue  0>  1>> 
cis?  Cvalue  1>  Cvalue  2»  IS  FALSE 
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SO 

<  <alter  2  C>  0> 

<is?  <value  0>  <value  2>>  IS  FALSE 
SO 

<put-brick-at  1  0> 

<_  <alter  0  1>  <♦  Cvaiue  0>  1>> 

<!s?  <value  1>  < value  2»  IS  FALSE 
~0 

<put-brick-at  <value  1>  <value  1>> 

<  <alter  1  2>  <♦  <value  1>  1>> 

<f  <alter  1  2>  <+  <value  1>  1>> 

<is?  <value  2>  <value  2>>  IS  TFOE 
SO 

[]» 

By  introducing  identifiers  for  the  constants  and  by  tracing  the 
bindings  of  the  identifiers  of  B UILD-TCWER  the  protocols  can  be 
arranged  in  a  tree  as  follows: 

new  [w  h] 

new  [ ww= UN ASSIGN ED;  hh=UNASSlGNED] 

i  « « 

if  <is?  .wv  .w> 
then 
t  ] 

else  <_  : hh  0>  if  <is?  .hh  .h> 
then 

<_  :ww  <♦  .ww  1>> 
if  <is?  .ww  .w> 
then 

C  3 

else 

<_  : hh  U> 
if  <is?  .hh  0> 
then 

<_  :ww  <♦  .ww  1>> 

if  <is?  .ww  ,w> 
then 
[  ] 

else. . r 

else. . . 

else 

<put-brick-at  .ww  .hh> 

<_  :  hh  <♦  .hh  1» 
if  <is?  -hh  .h> 
then 

<_  :ww  <  +  .uv  1>> 
if  <is?  .ww  1> 
then 
[  } 
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else 

<_  :hh  0> 
if  <is?  .hh  .h> 
then 

<put-brick~at  .ww  .hh> 

<_  : hh  <+  .hh  1>> 

if  <is?  .hh  .h> 
then 

<_  :ww  <+  . ww  1» 
if  <is?  .ww  .w> 
then  [  ] 
else. . . 

else. . . 

else. • . 

else 

<_  : hh  <*  .hh  1>> 
if  <is?  .hh  .h> 
then 

<_  : ww  <+  ,ww  1>> 
if  <is?  .vu  .w> 
then  [ ] 
e  xs  60 . . 

else.  . . 


He  define  the  protocol  of  an  evaluation  to  be  a  list  of  the 
events  and  the  places  in  the  program  where  they  happen  that  occur  when 
the  evaluation  is  being  carried  out.  By  examining  the  protocols  of 
the  system  as  it  tries  to  build  a  mall  me  find  that  it  always  uses  the 
same  procedure.  Of  course  it  mill  not  almays  be  the  case  that  the 
protocols  from  the  solutions  of  the  instances  of  a  goal  can  be 
combined  into  a  procedure.  The  basic  idea  is  to  combine  the  set  of 
protocols  into  a  tree  and  then  consider  any  tmo  nodes  of  t«e  tree 
mhich  cannot  be  distinguished  on  the  basis  of  the  protocols  to  be 
identical.  In  ether  words  it  is  necessary  to  compute  a  minimal  or 
almost  minimal  homomorphic  image  of  the  set  of  available  protocols. 
Unfortunately  it  is  often  difficult  to  extract  the  information  needed 
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to  do  procedural  abstraction  fro®  the  protocols  produced  by  PLANNER 
theorems  as  they  solve  problems.  The  procedure  that  the  theorem  is  in 
fact  using  can  he  expressed  as  follows: 


<define  compile- build  <functicn  [w  h] 

<overall  [  ] 

! ;  v intention  [  ] 

<and 

<goal  !*<is?  !'<non-neg>  .  w» 

<goal  !*<is?  !,<noc-*neg>  ,  h>»> 

<and 

<assert  !  *  <is?  !*<non-neg>  .w» 

<assert  !*<is?  ! ‘<non-neg>  .h>>>> 
<repeat  column 
[[ww  C]] 

! ; <intention  [  ] 

<goal  [wall  .ww  .h]> 

<assert  [wall  .ww  .h]>> 

<cond 

[<is?  .ww  . w > 

<intent  <wall  .w  .h>> 

<.column> 

;"exit  .column"  ]> 

<repeat  height  [[hh  0]] 

I ; Cintenticn  [  ] 

<goal  [column  .ww  .hh]> 

<assert  [column  .ww  ,hh]>> 

<cond 

[<is?  ,hh  ,h> 

<. height> 

;"exit  .height  with  <>"  ]> 

!  ;<intent  <goal  [  support-f or  .ww  .hh]» 
<put-brick-at  .ww  ,hh> 

!;<intent  <goal  [brick-at  .ww  ,hh]» 

<_  :hh  <♦  .hh  1>» 

<_  :ww  <+  .ww  1>>> 

<f unction  [  X ] 

<assert  [wall  .w  .  b  J> 

<goal  [wall  ,w  .h}»?> 

<define  check-wall 
<conseguent 
check-wall 
[w*  w  h*  h] 

[wall  ?w*  ?h»  ] 

Ccond 


[  Cor? 
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&<goal  ! • <is?  ?h‘  0>> 
S<goal  ! 1  <is?  ?w  *  0»>] 


w 

V 
, _ 1 

»<+  ?h 

1>  . h '  > 

<goal 

[wall  ?w» 

,h]> 

<goa  1 

[column  ?w 

»  ?h  • 

]>] 

[  <is?  ! 

?w 

1>  ,w'> 

<goal 

[wall  ?w  . 

h*  ]> 

<goal 

[column  Iv 

»  ?h* 

]>] 

[  -»welse 

(1 

<f  ail 

<>  .check- 

wall> 

A 

A 

A 

<define  check-column 
<conseguent 

check-column 
[»  h  h»] 

[column  ?w  ?h*J 
<cond 

[ 6<goal  !»<is?  ?h*  0>>] 

[ <is?  ! •<♦  ?h  1>  ,h'> 

<goal  [column  ?w  ?h]>] 

[  -«n<3lse" 

<fail  <>  ,check-column> ]>» 

<define  check-support 
<consequent 

check-support 
[v  h] 

[support-for  ?w  ?h  ] 

<cond 

[ &<goal  ! *<is?  ?h  0>>] 

[<goa.l  [column  .ww  ,hh]>] 

[  -•‘'else" 

<fail  <>  .  check-su  pport>  ]»> 

<define  put-brick-at 
<f unction  [  w  h  J 
<overall  [  ] 

<goal  [support-for  .w  .h]> 

<put-br ick-at  ,w  .h> 

<assert  [brick-at  .w  ,h]>»> 

The  IHTENDER  protocol  for  the  verification  of  the  intentions 
of  compile-build  is: 


<assert  !,<is?  !*<non-neg>  w_>> 
<assert  !*<is?  !‘<non-neg>  h_>> 
eater  intentions  of  repeat 
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Case  1:  initial  entry 
<assert  !'<is?  0  ww_>> 

<goal  [wall  0  h_]> 

enter  intentions  of  check-wall 
w*  brcoses  0 
h*  becomes  h 
<goal  !  *  <is?~h  0» 

FAIL 

<goal  ! ' <is?  0  0>> 

Case  2:  Inductively  assume 
<assert  [wall  ww_  h_  ]> 
enter  conditional 

Case  1: 

<assert  !*<is?  w_  ww_>> 

<goal  [wall  w_  h_]> 

Case  2: 

<asseri  !'<not  !*<is?  w_  ww_>>> 
enter  intentions  of  repeat 

Case  1:  initial  entry 
<assert  !'<is?  0  hh_>> 

<goal  [column  ww_  hh_]> 

enter  intentions  of  check-column 
w  becomes  ww_ 
h*  becomes  hh_ 

<goal  !’<is?  0  hh_>> 

Case  2:  inductively  assume 
<assert  [column  ww_  hh_]> 
enter  conditional 

CdS6  1  * 

<assert  !'<is?  hh_  h_>> 

<assert  J*<is?  ww_1  !*<♦  ww_  1>» 
<goal  [wall  ww_1  h_]> 
enter  intentions  of  check-wall 
v*  becomes  ww_1 
h'  becomes  h 

<goal  !'<is?~!*<+  ?h  1>  h_1» 
w  becomes  w_ 

<goal  [wall  w«_  h_]> 

CdS€  2  * 

<assert  !*<not  !*<is7  hh_  h_»> 

<goal  [support-for  hh_]> 
enter  intentions  of  check-support 
w  becomes  ww 
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h  becomes  hh_ 

<goal  [column  ww  hh_  ]> 

<assert  !'<is?  hh_1  !'o“hh_  1>» 

<goal  [column  ww_  hh_1  ]> 
enter  intentions  of  check-column 
w  becomes  ww_ 
h'  becomes  hh  1 

<goal  !*<is?  !•<♦  ?h  1>  hh_1» 

h  becomes  hh_1 

<goal  [column  ww_  hh_1]> 

Note  that  the  above  proof  tnat  CCMPILE-BUI ID  meets  its 
intentions  is  relative  to  the  PROCEDURAL  MODEL  that  we  have 
constructed.  The  procedural  model  is  constructed  out  of  procedures 
such  as  PUT-BRICK-AT.  The  procedural  model  is  connected  to  our  goal 
oriented  language  by  CORRESPONDENCE  BUIES  such  as  CHECK-SUPPORT. 

The  structure  of  the  abstracted  procedure  must  at  least 
reflect  the  structure  of  the  PLANNER  theorems  from  which  it  has  been 
abstracted.  Thus  the  abstraction  of  a  for-proved  loop  will  generate 
a  recursive  equation  which  might  be  simplified  to  a  loop.  Some  of  the 
recursion  in  abstracted  functions  is  primarily  generated  by  the 
structure  of  the  data  cf  the  problem.  If  we  consider  the  tags  column 
and  height  to  define  functions,  then  the  proof  is  essentially  by 
recursion  induction.  In  the  above  procedure  .w  is  the  width  of  the 
wall  to  be  built,  .ww  is  a  running  index  over  the  width,  . h  is  the 
height,  and  .bh  is  a  running  index  over  the  height.  Using  the 
intentions  in  the  above  procedure  as  subgoals  we  can  easily  see  that 
the  procedure  does  build  walls.  Notice  that  we  can  use  the  protocols 
of  the  procedure  [in  a  process  that  we  call  "protocol  rejection"]  to 
reject  false  subgoals  in  much  the  same  way  that  Gelernter  used 
diagrams  in  his  geometry  theorem  prover.  For  example  we  might 
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evaluate  Ccompile-build  1  2>,  Ccompile-build  2  1> ,  and  Cccmpi le-build 
3  2>  remembering  the  protocols  of  the  evaluations.  Thus  when 
considering  the  case  where  the  intention 

<intent 

Cor 

Cis?  .ww  0> 

Cwall  Csubl  .vu>  .hh»> 

is  evaluated  immediately  after  Cend  column>  is  evaluated,  it  will  be 
the  case  that  Cis?  .vw  0>  is  false  and  so  cannot  possibly  be  a 
provable  subgoal  even  though  it  implies  the  intention.  The  subgoal 
will  be  to  prove  [implies  Cnot  Cis?  .w  0>>  Cwall  Csubl  ,ww>  .hh>].  Of 
course  using  protocols  for  the  purpose  of  rejecting  false  subgoals 
does  not  help  us  to  eliminate  those  that  are  true  tut  unprovable. 

7.2. 2. 4.2  Bever.  ing  a  List  at  All  Levels 

Consider  the  following  protocols  for  a  procedure  r: 


Cnew  fa] 

Cis?  caonadic>  Cvalue  a»>  IS  TRUE 
SO  Cvalue  a> 

thus  Cr  a>  is  a 


Cnew  [[n]] 

Cis?  Caonadic>  Cvalue  [n]>>  IS  FALSE 
SO 

[ 

(new  [Crest  Cvalue  [  n  }»  ] 

Cis?  <monadic>  Cvalue  [  J>>  IS  TRUE 
SO  Cvalue  [  ]>} 
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Cnew  [CCvalue  [  n  ]>  1>] 

<is?  <raonadic>  Cvalue  n>>  IS  TRUE 
SC  <value  n>>]> 

thus  <r  [  n  ]>  is  [  n  ] 


Cnew  [  [a  b  ]  ] 

<is?  <monadic>  Cvalue  [a  b]>>  IS  FALSE 
SO 

[ 

{new  [  <rest  <value  [a  bj>>] 

<is?  <nonadic>  Cvalue  [b]>>  IS  FALSE 
SO 

[ 

{Cnew  [Crest  <value  [b]>>] 

<is?  Cmonadic>  Cvalue  [  ]>>  IS  TRUE 
SC  Cvalue  [  ]>>} 

<new  [CCvalue  [b]>  1>] 

<is?  <*onadic>  <value  b>>  IS  TRUE 
SC  <value  b»]} 

<new  [<<value  [a  b  J>  1>] 

<is?  <oonadic>  Cvalue  a>>  IS  TRUE 
SC  Cvalue  a>>]> 

thus  Cr  [a  b  ]>  is  [b  a] 


Cnew  [[[a]]] 

Cis?  CmonadiO  Cvalue  [[a]]>>  IS  FALSE 
SO 

[ 

{Cnev  [Crest  Cvalue  [[a]]>>] 

Cis?  Cacnadic>  Cvalue  [  ]>>  IS  TRUE 
SO  [  ]>} 

Cnew  [CCvalue  [£a]]>  1>] 

Cis?  Cncnadic>  Cvalue  [a]>>  IS  FALSE 
SC 

[ 

{Cnew  [Crest  Cvalue  [a]>>] 

Cis?  <monadic>  Cvalue  [  ]>>  IS  TRUE 
SC  [  ]>} 

Cnew  [CCvalue  [  a  ]>  1>] 

Cis?  Caonadic>  Cvalue  a>>  IS  TRUE 
SC  Cvalue  a>>]>]> 


thus  Cr  [[a]]>  is  [[a]] 

Ve  obtain  the  following  protocol  trt;e: 


Cnew  r  xl  1 

if  <is?  <aonadic>  .x1> 
then  .  xi 
else 

C 

(new  £  x2  <rest  ,x1>] 
if  <is?  Caonadic>  .  x2> 
then  ,x2 
else 
[ 

(new  [x3  Crest  .x2>] 
if  <is?  <Bonadic>  .x3> 
then  .x3 
else...} 

Cnew  [x4  <1  .x2>] 
if  <is?  Cmonadic>  .  x4> 
then  .x4 
else.  .  .  >  ]} 

Cnew  [ x5  Cl  .x 1> ] 
if  Cis?  C«cnadic>  .x5> 
then  .x5 
else 
[ 

(new  £x6  Crest  .x5>] 
if  Cis?  CocnadiO  .  x6> 
then  ,x6 
else. . . } 

Cnew  [x7  Cl  .x5>] 
if  Cis?  Caonadic>  ,x7> 
then  ,x> 
else. . . > ]>  ]> 


By  identifying  indistinguishable  nodes  we  obtain: 

Cdefine  super-reverse  Cfunction  f  x  1 
Ccond 

[Cis?  Caonadic>  .x> 

.x  ] 

£  -*Helse" 

[ 

(super-reverse  crest  ,x>} 
Csnper-re verse  <1  .x»j]>>> 
7.2.2. 4.3  Pinding  the  Description  of  a  Stick 
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Suppose  that  we  have  the  following  data  base: 
[block  a] 

[block  b] 

[glued  a  b] 


The  above  data  base  represents  a  stick  on  the  the  basis  of  the 
following  protocol: 


<goal  [stick  a  b1> 

<new  [ UNASSIGNED  UNASSIGNED  ONASSIGNED  ] 

;”we  have  three  new  identifiers  that  do  not  have 

values” 

consequent:  [stick  <given  ONASSIGNED  a>  <given  ONASSIGNED  b>  ] 
cond 

<current  [glued  <given  a>  <given  b>]> 

<return  t>> 

Now  suppose  that  the  data  base  is; 

[block  a] 

[block  b] 

[block  c] 

[glued  a  b] 

[glued  be] 

[between  a  b  c] 

We  obtain  the  following  protocol: 

<goal  [stick  a  c]> 

[new  ONASSIGNED  ONASSI,  .  'SIGNED] 
consequent:  [stick  <9^  iven  c>] 

cond 

<current  [glued  <gi»iu  a>  <given  c>]> 
fail 

<current  [block  <given  a>]> 

<goal  [glued  <value  a>  <_  ONASSIGNED  b>]> 

<current  [between  <value  a>  <value  b>  <given  c>]> 

<goal  [stick  <value  b>  <value  c>]> 

[new  ONASSIGNED  ONASSIGNED  ONASSIGNED] 
consequent;  [stick  <giyen  b>  <given  c>  ] 
cond 

<proved  [glued  <given  b>  <given  c>]> 

<return  t> 


f1 . 


[block  q] 
[block  bl 
[glued  a  b3 


FIGURE  I 


[block  a3 
[block  b3 
[block  c 3 
[glued  a  b] 

[ glued  b  c3 
C between  a  be] 

FIGURE  2 


[block  al 
[block  b] 

[block  c] 

[glued  o  b] 

[glued  b  c3 

[not [between  a  b  c33 


FIGURE  3 


7.2  page  325 


8y  variabalization  we  obtain  the  following  protocol  tree: 

<goal  [stick  a  v  ]> 

[new  x  y  z] 

consequent  cl:  [stick  ?x  ?z] 

<cond 

[6<goal  [glued  i’x  ?z  ]> 

<.c1  t> 

;"exit  .cl  with  t"  ]> 

<current  [block  ?x ]> 

<goal  [glued  .z  _y  ]> 

<current  [between  .x  .y  ?z  J> 

<goal  [stick  .y  .z  ]> 

[ new  x  1  y  1  z  1  ' 

consequent  c2:  [stick  ?x1  ?z1] 

<cond 

[ 6<goal  [glued  ?x  1  ?z1]> 

<.c2  t> 

;Mexit  ,c2  with  t"  ]> 

<current  [block  ?x1J> 

<goal  [glued  .xl  _y1 ]> 

Ccursent  [between  .xl  .yl  ?z1]> 

<goal  [stick  .yl  .zl  ]> 

By  identifying  indistinguishable  nodes  ve  obtain  the  following 
consequent  theorem  which  is  the  description  of  a  stick. 


<de£ine  stick-des  jtion  <ccnsequent  c 
[x  y  z] 

•  [sti'tk  ??.  <z] 

<cond 

.  -<goal  [glued  2x  ?z]> 

c  *> 


..•‘c.tJt  .c  with  tn  ]> 
<curren  -  f  t ;  c-.  1  ?x  ]> 

<goal  [gjt.  .-c  ,x  _y  ]> 

<currer,t  [between  .x  ,y  ?z]> 
<goal  [sti  k  .y  .z]>>> 


7. 2. 2. 4-4  Pinding  the  Fibonocci  lawbers  Iteratirely 
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Sometimes  it  is  possible  to  improve  the  efficiency  of  a 


procedure  by  procedural  abstraction.  For  example  consider  the 

protocols  of  the  schema  f  defined  below. 

<define  f  <f unction  [n] 

<cond 

[ <or  <P  .n>  <P  <S  .n»> 

<OHE>] 

[-•"else** 

<A  <f  <S  .  n»  <f  <S  <S  .  n»>>  ]»> 


He  shall  used  the  abbreviation  that  <£-»0  x>  is  x  and  <f-»n+1  x>  is  <f 
<f-»n  x»  where  f  is  a  function.  Thus  <f->2  x>  is  <f  <f  x».  The 
protocol  for  the  above  schema  is: 


if 


<or  <P  <S-*0  n»  <P  <S-»1  n»> 
then  <ONE> 
else 

<A 

if  <or  <P  <S-«1  n»  <P  <S-*2  n»> 
then  <GNE> 
else 
<A 

if  <or  <P  <S-*2  n»  <P  <S-»3  n»> 
then  <CHE> 
else. . . 

if  <or  <P  <S-»3  n»  <P  <S-.4  n»> 
then  <0JIE> 
else. . .> 

if  <or  <P  <S-2  n»  <P  <S-3  n»> 
then  <CHE> 
else 
<A 

if  <or  <P  <S-*3  n»  <P  <S-.4  n»> 
then  <0S£> 
else. . . 

if  <or  <P  <S-«4  ns>  <P  <S-»5  n»> 
then  <0 NE> 
else. . . >> 


By  procedural  abstraction  we  can  obtain  a  function  fl  wiich  is 
equivalent  to  f.  rhe  function  is  obtained  by  identifying  some  ox  the 
nodes  that  are  not  on  the  sane  branch  of  the  protocol  tree. 
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<define  £  <li.ncti.on  out  [n] 

<cond 

[<or  <P  .n>  <P  <S  .  n>» 

< •  out  <ONE>  <CXE»] 

[  -t"else" 

<call 

<f  <S  .n» 

<f unction  [downl  down2j 
<.out 

<A  .downl  .down2> 

.  downl  »>  ]»> 

Another  approach  is  to  use  sene  of  the  theory  of  recursive  schemas. 
The  function  f  defined  above  is  schematically  equivalent  to  the 
function  £f  defined  below 


<define  ff  <f unction  £f  f n  ] 

<for  [[x  0]  [y  0  J] 

[[-•"test"  <P  .n>  <.ff  .x>  ;"exit  .ff  with  .x"] 
[-•"step"  <_  :n  <S  ,n»?] 

<_  :y]  <tuple  <A  .x  .y>  .x>> 

;,Jthe  previous  statement  is  just  a  tricky  aay  to 

simultaneously  accomplish  <__  :x  <A  .x  .y» 
and  <_  :y  .x>">>> 


Hote  that  <fib  n>  the  nth  Fibonacci  nuaber  can  be  defined  as  follows 


<define  fib  <f unction  [n] 

<cond 

[<or  <is?  1  .n>  <is?  2  .n>> 

n 

[-•"else" 

<♦  <fib  <-  .n  1»  <-  .n  2»J»> 


Csing  the  interpretation  that  <OKE>  is  1,  <P  x>  tests  to  see  if  x  is 
1,  and  A  is  add,  we  see  that  the  function  fib  can  be  rewritten 
iteratively. 

The  process  of  procedural  abstraction  is  very  much  like  » 
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generalized  fora  of  compilation.  The  relationship  between  the 
compiled  version  and  the  interpreted  version  can  be  very  subtle.  In 
classical  compilers  the  relationship  is  such  more  straightforward. 
Every  time  that  the  interpreter  for  the  language  changes  the  compiler 
must  change.  In  fact  the  interpreter  and  compiler  are  two  moaes  of 
what  is  essentially  cne  program  an  interpreter-compiler.  In  compile 
mode  it  would  actually  produce  the  compiled  code  for  the  source  code; 
in  interpret  mode  it  would  take  the  actions  corresponding  to  the 
compiled  code  that  wculd  be  produced  in  compile  mode.  The 
interpreter-compiler  can  be  written  it  HATCHLESS  so  that  in  compile 
mode  the  HATCHLESS  skeletons  have  as  value  the  compiled  code.  One 
problem  with  interpreter-compilers  is  that  they  suffer  from  the 
inefficiency  of  double  interpretation.  Instead  of  directly 
interpeting  the  expressions,  in  interpret  mode  the  interpeter-cof piler 
interprets  the  skeletons  that  would  produce  the  code  in  compile  mode. 
The  problem  can  be  solved  by  compiling  the  interp  •  cer-compiler  for 
interpret  mode.  He  would  like  to  try  to  extend  this  idea  to  PLAHNER 

»  •  v  —  * 

in  a  more  nontrivial  way  so  that  goals  would  be  created  to  produce  the 
compiled  code. 

7. 2. 2. 4. 5  Defining  a  Data  Type 

He  can  do  procedural  abstraction  of  protocols  along  the  same 
lines  for  actors.  For  example  if  we  obtain  the  following  actor 
protocol 
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£ <when 

[[  ?J 

[ <atoaic>  ] 
f <when 

£[]] 

£<atonic> ] 

£ <when 

[[  ]J 

£  <atcaic> ]> ]> 

{when 

[[]] 

£<ato»ic>] 

[ <vhen 

a  j] 

[ <ato«ic> ] 

[ <when 

[[  J]> 

(when 

CL33 

[  <atoaic>  ]}  ]>]}  ]>] 


Then  by  identifying  equivalent  nodes  we  obtain  the  actor  expr  where 


<define  expr  factor  £  J 
<when 

[[]] 

[<atomic>] 

£[<expr>  £expr}’]>» 

Goodstein  has  aany  inductive  proofs  of  the  the  properties  of 
recursive  programs.  John  HcCarthy  was  one  of  the  first  to  popularize 
the  use  of  recursion  induction  for  proving  the  properties  of  programs. 
The  easiest  way  to  do  recursion  induction  is  to  provide  at  least  one 
predicate  for  each  recursive  equation,  fiobert  Floyd  has  proposed  that 
predicates  in  the  first  order  guantificational  calculus  be  attached  to 
the  edges  of  flow  charts  in  order  to  provide  subgoals  for  proofs  of 
properties  of  programs,  in  general  we  would  prefer  to  proceed  «ore 
constructively  and  to  write  intentions  in  PL1HN2B  rather  than  in  a 
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fora  of  the  quantif icational  calculus.  Finding  aq  intuitionistic 
proof  of  a  sentence  in  first  order  logic  is  the  same  problem  as 
finding  a  recursire  function  that  realize  the  the  foraula.  Since  the 
logistic  system  of  PLANNEE  is  very  constructive,  a  proof  of  a  PLANNEE 
theorea  entails  being  able  to  vrite  the  procedures  vhich  compute  the 
values  that  identifiers  in  goa1  ••  take  cn  as  a  result  of  the  goal  being 
established.  Intentions  are  a  first  step  toward  constructing  models 
of  the  environment  in  which  a  process  executes.  He  need  to  develop 
good  ways  to  increase  the  expressive  cover  cf  intentions.  Currently 
the  model  of  ibe  computation  must  be  expressed  by  intentions  within 
the  process  being  executed  which  makes  it  difficult  to  get  a  global 
view  of  tne  model  of  the  execution  of  the  process.  The  application  of 
intentions  in  which  we  are  most  interested  is  their  use  to  provide 
subgoals  to  enable  us  to  deduce  PLANNEE  theorems  with  loops  in  them. 

He  shall  say  that  an  intenticn  i  characterizes  a  function  f  if 
whenever  <f  x>  converges  then  <equal  <f  x>  y>  if  and  cnly  if  <i  x  y> 
is  true.  A  leng  time  ago  Johu  HcCarthy  and  others  proposed  that  tne 
debugging  problem  be  solved  by  proving  that  the  procedure  is  correct 
once  and  for  all.  Using  induction  HcCarthy  and  his  students  have 
proved  that  certain  compilers  are  correct.  The  most  important 
practical  difficulty  to  the  realization  of  the  proposal  is  that  for 
many  functions  f  written  in  higher  level  languages  it  seems  that  all 
the  intentions  that  characterize  f  are  at  least  as  long  as  f  because 
the  only  way  to  tell  whether  the  value  of  <f  x>  is  correct  or  not  is 
to  do  an  equivalent  computation  all  over  again.  A  good  example  of 


7.2  page  331 


such  a  function  is  eval  in  LISP.  The  function  eval  is  an  extreme 
exaaple  of  a  function  that  has  no  simple  declarative  input  ouput 
characterization.  A  real  challenge  in  antonatic  progran  writing  is 
tc  develop  a  symbolic  inetegration  routine  froa  the  criteria  that  the 
derivative  of  the  answer  aust  be  equivalent  to  the  input.  One 
approach  toward  constructing  such  a  routine  would  be  to  nake  use  of 
soae  results  of  Risch  oa  what  aust  be  the  fora  of  the  integrand  as  a 
function  of  the  fora  of  the  integrand.  In  the  case  of  the  factorial 
function  there  are  two  obvious  ways  to  coapute  the  function:  using 
recursion  or  using  a  loop.  In  other  cases  it  is  not  so  obvious  how  to 
find  a  sufficiently  different  equivalent  progran.  We  shall  say  that 
an  intention  i  is  implied  by  a  function  f  if  whenever  <f  x>  converges 
then  if  <egual  <f  x>  y>,  then  <i  x  y>  is  true.  Iaplied  intentions  are 
useful  when  we  are  only  interested  in  soae  property  of  the  function 
and  don’t  care  to  try  to  characterize  it  coapletely.  For  exaaple  we 
night  not  care  whether  a  function  that  deteraines  how  to  stack  cubes 
always  puts  red  cubes  on  the  botton  of  the  tower  that  it  is  trying  to 
build.  Or  we  aight  be  interested  in  proving  that  a  scheduler  for  a 
tine  sharing  system  passes  so-e  test  for  fairness  in  its  distribution 
of  tiae  to  users.  Another  potential  use  for  implied  intentions  is  to 
provide  subgoals  to  prove  that  a  given  function  that  uses  lock  and 
unlock  and  unliaited  use  of  assignment  in  parallel  computations  is 
indeed  deter ainate. 

A  nore  serious  problea  is  that  often  we  cannot  develop 
reasonable  iaplied  overall  intentions,  consider  trying  to  write 
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intentions  foe  a  chess  program.  We  could  require  that  the  program 
play  LEGAL  chess  but  this  is  the  least  of  considerations.  How  can  we 
write  intentions  to  the  effect  that  the  program  should  play  GOOD 
chess?  There  is  a  completely  trivial  program  which  will  play  PEBPECT 
chess  given  sufficient  time  and  storage.  However,  the  amount  of  time 
and  storage  required  are  wildly  impractical.  One  might  believe  that 
the  problem  of  writing  overall  intentions  afflicts  only  game  playing 
programs.  However,  the  same  problem  arises  in  trying  to  write 
overall  intentions  for  a  robot.  We  can  specify  in  detail  a  certain 
finite  number  of  elemertary  procedures  which  the  robot  should  be  able 
to  perform.  In  a  given  situation  there  may  be  some  obscure  way  for 
the  procedures  to  interract  to  provide  a  solution  for  a  problem. 
However,  it  is  not  fair  to  blame  the  robot  for  not  solving  a  very 
difficult  problem.  Thus  we  again  have  a  problem  writing  realistic 
overall  intentions. 

7.2.3  Teaching  Procedures  by  Deducing  the  Bodies  of  Canned  Loops 

If  the  type  cf  control  structure  is  known  a  priori,  then  the 
rest  of  the  function  can  often  be  deduced.  Often  the  control 
structure  needed  is  a  very  commonly  used  loop  such  as  the  FOB  loop  in 
HATCHLESS,  recursion  on  the  tree  structure  of  lists,  or  one  of  the 
loops  in  PL&HKEB  such  as  TBY,  FIND,  or  EXHAUST.  We  shall  call  loops 
such  as  the  above  ^canned*  loops  since  we  will  often  pull  them  out  and 
use  them  whole  when  we  are  in  need  of  a  control  structure  for  a 
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routine.  The  approach  of  using  canned  loops  is  the  one  used  by 
Kieene  for  constructive  realization  functions  for  intuitionistic 
logic.  Suppose  that  we  know  the  following  theorem  about  the 
predicate  [REVERSE?  x  y]  which  means  that  y  is  the  reverse  of  x.  For 
exanple  [reverse?  aa  aa]  and  [reverse?  [1  2  [3  4]]  [[3  4]  2  1]]  are 
true.  As  before  •  is  used  to  suppress  invocations,  and  a  monad  is 
defined  to  be  at  atom,  ^  number,  [  ],  or  [  ].  The  function  IDENTITY 
which  is  used  below  is  the  identity  function. 


<define  th69  Consequent 
[a  b  c  ] 

[reverse?  ?a  ?fc] 

Ccond 

[Chasval?  a> 

<cond 

[6<goal  !*<aonad?  .a» 

;Mif  a  is  a  monad  then  b  should  be  equal  to  a" 
<goal  !’<is?  -a  ?b>>] 

[  -'•’else" 

<goal  if<not  l»<aonad?  ,a>» 

<goal  [reverse?  !* Crest  ,a>  _c  ]> 

; "otherwise  let  c  be  the  reverse  of  the  rest 

of  a" 

<goal  ! f  <is?  ['(identity  .c}  !  •  <  1  -a>]  ?b»j>] 
[  ."else"  <£ail>]»> 

He  would  like  to  find  a  function  reverse  such  that  [reverse?  x 
[reverse  x]]  is  always  true.  The  theorem  above  suggests  that  we  try 
to  use  linear  induction  on  lists  as  the  control  structure.  The  schema 
for  linear  induction  applied  to  the  function  reverse  is: 


<define  reverse  <f unction  [x] 

! *  Ccond 

[  !  'Cnonad?  .x> 

Cteaprog  [ I  ] 

Casscrt  1* Cnonad?  .x>> 
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<goal  [reverse?  .x  _Y  ]> 

: ;"find  a  T  which  is  the  reverse  of  the  aonad 
x  and  return  it  as  value" 

.Y>] 

[-'"else" 

Cteaprcg  [  Y ] 

<assert  !*<not  M<sonad?  .x»> 

<assert  [reverse? 

!*<rest  ,x> 

!*<reverse  !*<rest  .x>>]> 

<goal  [reverse?  .x  _Y ]> 

. Y  >  ]>>> 

The  above  expression  evaluates  to  the  following  definition: 


<define  reverse  <f unction  [x] 

<cond 

[<nonad?  .x> 

.x] 

[  -•"else" 

[  {identity  <reverse  <rest  .  x») 
<1  .x>]]>» 


7.2.4.  Coaparison  of  the  Methods 


Superficially  considered,  there  is  not  auch  to  be  said  about 
teaching  procedures  by  telling.  It  is  not  always  clear  whether  the 
procedure  should  be  taught  fro*  the  top  down  or  the  priaitives  should 
be  taught  first.  However,  the  basics  of  the  aethod  are  siaple  and 
direct.  Onf ortunatoly  the  teacher  will  not  always  know  the  code  for 
the  procedure  which  is  to  be  taught.  Be  night  be  engaged  in  wishful 
thinking  hoping  to  find  a  procedure  with  certain  properties.  The 
■ethod  of  canned  loops  is  often  applicable  to  such  cases.  Trving  to 
use  the  aethod  of  canned  loops  has  the  problea  that  the  control 
structure  aust  be  supposed.  Often  it  is  very  difficult  to  guess  the 
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kind  of  control  structure  which  will  prove  appropriate.  Also  the 

oethod  of  canned  loops  works  on  the  problem  in  the  abstract  as  opposed 
to  specific  exasples  where  the  identifiers  are  bound  to  actual  values. 
The  advantage  of  the  abstract  approach  is  that  if  it  succeeds  then  the 
procedure  will  be  known  by  its  construction  to  hate  certain 
properties.  On  the  ether  hand  it  is  often  easier  to  see  what  to  do 
on  concrete  cases.  Often  it  is  easier  to  show  someone  how  to  do 
something  than  to  tell  hia  how  to  do  it.  Partly  this  is  because  the 
descriptive  language  necessary  has  not  been  adequately  developed  and 
so  we  use  "body  language".  The  approach  of  procedural  abstraction  is 
to  'oabine  together  several  concrete  cases  into  one  sueposed  general 
procedure.  Properties  of  the  general  procedure  aust  then  be 
established  by  separate  arguaent.  If  the  protocols  of  the  examples 
are  produced  by  a  goal-oriented  language  such  as  PLAHNBB,  then  there 
will  be  points  along  the  protocols  where  certain  predicates  arc  known 
to  be  true.  The  predicates  express  the  fact  that  soae  goal  was 
established  as  true  at  that  point.  Often  it  is  possible  to  show  by 
aatheaatical  induction  that  the  corresponding  properties  in  the 
abstracted  procedure  are  always  true  when  the  procedure  passes  through 
the  points,  in  this  ay  a  problea  solver  can  have  a  partial  aodel  of 
his  problea  solving  procedures.  The  aodels  can  be  expressed  naturally 
in  PLAHMEB.  Also  the  aethod  of  procedural  abstraction  has  the 
advantage  that  the  control  structure  doe*>  not  have  to  be  supposed  in 
advance.  often  a  problea  solver  will  have  the  basic  problea  solving 


ability  to  solve  any  one  of  a  certain  crass  of  problems.  But  he  will 
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not  know  that  he  has  the  capability.  Writing  a  procedure  which  can  be 
shown  to  solve  the  class  enables  the  problem  solver  to  bootstrap  on 
his  previous  work.  Procedural  abstraction  itself  is  further  evidence 
for  the  Principle  of  Procedural  Embedding.  To  implement,  the  principle 
as  a  research  program  requires  a  high  level  goal-oriented  formalism. 
PLANNER  and  some  embellishments  that  w  have  made  to  the  language  are 
first  steps  toward  realizing  the  Principle  of  Procedural  Embedding. 
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7.3  Current  Prcbleas  and  Puture  K;irk 


Currently  we  have  mechanisms  to  handle  the  following  kinds  of 
"bugs"  or  "local  changes"  in  programs: 

MI SIDENTIFICATION  of  NODES:  If  two  nodes  of  a  protocol  have 
been  mistakenly  identified  as  being  the  same  then  the  mistake  can  be 
corrected  from  new  protocols  which  distinguish  the  nodes. 

VARIAB  ALIZATIC  N:  Procedures  can  be  made  more  general  by 
changing  some  of  their  constants  into  variables. 

PATCHES:  Existing  routines  can  sometimes  be  converted  into 

the  desired  procedure  by  introducing  new  intentions  into  them.  The 
patch  is  produced  by  the  code  generated  by  the  new  intention  as  it  is 
evaluated  by  INTENDER  in  the  environment  in  which  it  was  placed.  Of 
course  a  bug  is  suspected  at  the  point  where  an  ordinary  intention 
cannot  be  verified. 

fie  need  to  find  ways  to  improve  the  existing  mechanisms  and  to 
find  ways  to  handle  other  kinds  of  bugs  and  local  changes.  Also 
procedural  abstraction  must  be  generalised  to  accept  higher  level 
protocols  and  to  make  better  nse  of  existing  procedural  knowledge  in 
doing  the  abstraction. 
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8.  More  Comparative  Schematclcgy 


Abstract 


Schemata  are  programs  in  which  some  of  the  function  symbols 
are  uninterpreted.  In  this;  chapter  we  compare  classes  of  schemata  in 
which  various  kinds  cf  constraints  are  imposed  on  some  of  the  function 
symbols.  Among  the  classes  of  schemata  compared  are  program, 
recursive,  backtrack,  and  parallel. 
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8.1.  Analytic  Theory 

8.1,1  Classes  of  Scheaata 

8.  1.1.1  fiecursi^e  Sche.iat'i 

The  following  is  an  inforaal  progress  report  of  soae  work  that 
I  have  done  with  Hike  Paterson.  John  1.  *hite  sale  .important 
suggestions  and  corrections.  The  result  that  recursive  schemata  are 
aore  powerful  than  prograa  scheaa  was  obtained  as  a  terr  project  in 
the  spring  of  1969.  Higorous  proofs  are  not  given  here  but  just  an 
indication  of  how  a  prcof  would  go.  Prograa  scheaata  are  nourecursive 
procedures  that  have  uninterpre'ced  function  symbols  and  predicate 
syabols.  He  shall  use  capital  letters  to  denote  uninterpreted 
syabols.  He  assuae  that  within  each  computing  dosain  that  there  is  a 
distinguished  element  denote  i  by  false  an*  that  all  other  eleaents  of 
the  computing  domain  are  regarded  as  true  in  conditional  expressions. 
Thus  we  do  not  need  to  distinguish  between  predicates  and  other 
function1.,.  iteration  within  program  scheaata  is  performed  by  BEPEAT 
loops.  Bepeats  are  defined  so  that  (repeat  <body>)  will  repeatedly 
execute  Cbody>  un.il  a  (return  <ralues>)  stateBcnu  is  encountered  at 
which  point  control  is  transfered  out  of  the  smallest  er«‘.;osing  block 
with  tk(-  indicated  values.  Blocks  can  be  given  njaes  and  the  function 
(exit  <uaae>  <values>-;  will  cause  control  t~  leave  the  -aaod  block 
with  the  appropriate  values.  It  is  evsy  to  see  that  any  program 
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schema  in  the  sense  of  Patterscn  can  he  written  using  REPEAT  and  EXIT 
with  out  the  use  of  GO.  Writing  iterative  ccaputations  using  REPEAT 
and  EXIT  has  the  advantage  that  all  the  loops  are  cf  necessity  nested. 
We  shall  allow  scheaata  to  use  a  finite  number  of  distinguished 
objects  which  can  be  tested  by  the  binary  predicate  IS.  For  example 
{is  x  "hello")  is  true  only  if  x  is  the  distinguished  constant 
"uello"'.  Functions  evaluate  their  arguments  froa  left  to  right. 

The  following  is  an  exaaple  of  a  prograa  schema: 

(g  x)  =  (repeat  {(y  <-  x) ) 

;"y  is  a  a  register  cf  the  program  schema  g  which  is 
initialized  to  the  value  of  the  arguaent  x" 

(if  (cr  (P  x)  (is  x  "dolly"))  then  (return  yj  ) 

(x  <-  (L  y)) 

(y  <-  (E  (B  y)))) 

The  BMF  syntax  for  prograa  schemata  is  as  fellows: 


program  =  <ters> 
term  ::=  <hlcck>  | 

<repeat>  j 
<again> 

<oxit> 

(if  <tera>  then  <teras>  else  «s>)  { 

<assignnept>  J 
false  1 

<literal-st ring>  | 

<identii;ier>  { 

<f u net ion- call > 
block  ::=  (block  <body>) 
assignment  ::=  (<identif ier>  "<-*  <tera,-) 
repeat  ::=  (repeat  <body>) 

function-call  {<  .iinterpreted-.furction>  <arguaents>)  ] 

(is  <ter*>  <tera>)  | 

•call 

(<unintc'rpreted-f unction>  <arguaents>) 

<f  unction.'-) 

again  .* :  =  (again)  )  (again  <na»e>) 

exit  ::=  (erit  <na«g^  <teras>)  |  (return  <taras>) 
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body  ::=  <na»e>  <declaration>  <terms>  | 

<declaraticn>  <terns> 
terns  <ter*>  j  <ter*>  <texns> 
declaration  (<identifiers>) 

arguments  ::=  ]  <terms> 

identifiers  1  <identifier>  <identif icrs> 

A  recursive  schema  is  a  program  schema  that  is  allowed  to  call 
itself  or  other  recursive  schemata  recursively.  She  following  is  an 
example  of  a  recursive  schema  k.  which  is  defined  by  a  set  of  recursive 
equations: 


(k  7)  3  (if  (P  r)  then  x 

else  (C  (k  x)  (a  (B  x))  > ) 

(m  y)  =  (if  (P  (R  y) )  then  (L  y) 

else  (C  (m  (1  y) )  (k  (k  s) ) ) ) 

Por  any  recursive  scnema  defined  by  a  set  of  r««-uraive  eguations  we 
can  ccastruct  ac  equivalent  recursive  schena  with  only  one  equation 
and  one  additional  arguient  to  tell  which  equation  is  being  simulated. 
This  is  possible  .because  we  allow  recursive  schemata  to  use  a  finite 
number  of  distinguished  constants  and  predicates  to  test  for  these 
constants.  The  following  is  an  example  of  a  recursive  schema  that 
uses  the  interpreted  constant  symbols  true  and  false. 


(f  x)  =  (if  (P  x) 
then 

(if  <Q  x) 

then  true 
else  false) 
elseif  (f  (L  x}) 

then  true 
else  (f  (B  x))) 


i 

; 


8.1.  1.1.1  Comparison  with  Program  Schemata 
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In  fact  tfce  abcve  recursive  schema  is  not  equivalent  to  any  program 
schema.  Dy  equivalent  we  mean  that  the  t*j  schemata  must  both  fail 
to  terminate  or  both  oust  return  the  same  value  for  all 
interpretations  of  the  functions  Pf  L,  and  B.  Cften  ve  will  take 
the  set  of  unincer preted  terms  as  our  domain  of  interpretation.  In 
the  above  case  the  domain  of  interpretation  is  x  (Lx),  (B  x)  ,  (L  (L 
x)),  (L  (B  x)},  (B  (L  x)),  etc.  The  function  letters  L  and  B  are 
interpreted  as  1  and  r  where: 

(1  y)  is  defined  to  be  the  term  (L  y) 

(r  y)  is  the  term  (H  y) 

Thus  (1  (5v  (L  x)))  is  the  term  (L  (B  (L  x) ) )  .  Two  schemata  are 
equivalent  if  and  only  if  they  define  the  same  function  on  the  domain 
of  terms. 

Theorem: 

The  function  f  defined  above  is  not  equivalent  to  any  program  schema. 
Proof:  Consider  the  following  class  of  interpretations  {I  n}  where  n 

is  a  non-negative  integer: 

The  domain  of  interpretation  is  the  set  _-f  terms  that  can  be 
constructed  tram  the  indeterminate  x  and  the  predicate  letters  L  and 
B.  The  predicate  Q  is  interpreted  as  a  function  q  with  range  (true 
false}.  The  predicate  P  is  interpreted  as  the  function  p: 

(p  (h//C  .  ..(h//n  x)...})  -  true  fee  m  =  c 


I 
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=  false  otherwise 


where  each  h//i  {"h  subscripted  by  iw}  is  the  interpretation  for  8  or 
the  interpretation  for  L  and  there  is  at  lost  one  path  such  that 


(g  {h//0. . . (h//n  x)...))  *  true 

The  domain  of  {I  a}  is  the  set  of  all  tens  that  can  be  constructed 


xroB  the  icdeterxinate  x  and  the  functions  L  and  B.  He  are  going  to 


prowe  that  fo  .  any  progra*  schema  P  we  can  find  an  integer  t  such  that 
P  does  not  define  the  sale  function  as  the  recursive  scheaa  f  on  at 


least  one  aeaber  of  the  class  {I  n}.  In  the  the  interpretation  {I  3], 
we  have  the  following  I-B  tree  {where  each  node  is  a  ter«  in  the 


doaaia  of  {I  3}): 


ML  x) 

ML  (L  x)) 

ML  {L  (Lx)))} 

UR  (L  (L  x)))}} 
MB  (L  X)) 

l  (L  <R  (L  X)))> 

MB  <H  (LX)))}}} 

MB  X} 

{(L  (B  X). 

ML  {L  (B  X)  )  )  1 
(<B  (L  *B  X)))}} 
MB  (B  X)) 

{(L  (B  {B  X)))} 

{<B  (B  (H  X}))}}}} 


The  function  p  is  true  only  oi  the  rightmost  (i.e.  bottca)  ncdes  and 


q  is  true  on  at  aost  one  of  the  right-uost  (bottoa)  nodes.  He  shall 
define  the  state  of  a  prograa  scheaa  P  at  a  point  in  its  computation 
to  be  the  contents  of  the  registers  of  P  together  with  the  stateiwtut 
of  p  that  will  be  executed  next.  Two  states  Si  and  S2  of  P  under  the 


interpret tion  1  will  be  said  to  be  EQ0I?hL£HT  if  p  executes  exactly  the 


same  sequence  of  instructions  when  started  from  SI  as  when  started 
from  S2.  He  shall  define  the  number  of  statements  of  a  program  schema 
to  be  the  total  number  of  left  parentheses  in  the  text  of  the  program 
schema.  Suppose  we  haMe  a  program  schema  P  with  s  statements  and  k 
registers.  In  the  interpretation  {I  n} ,  the  program  schema  P  has  at 
most  s*((n*2)-»k)  equivalence  classes  of  states  where  is  the 
exponential  function.  (Intuitively  the  only  thing  the  schema  ran  do 
is  tc  count  down  each  of  its  k  registers  to  the  bottom  of  the  L-H  tree 
and  test  each  of  them  to  see  if  it  has  reached  the  bottom.)  However,  a 
program  schema  needs  at  least  2-«n  steps  in  order  to  check  if  g  is  true 
on  each  of  the  nodes  at  level  n.  But  after  2-*n  steps,  P  must  be  in  an 
infinite  loop  since  it  will  have  arrived  at  two  distinct  nodes  of  the 
L  R  tree  in  the  same  equivalence  class  of  states.  To  see  the  matter 
somewhat  differently  look  at  the  seguence  of  equivalence  classes  of 
states.  If  the  sequence  repeats  then  the  program  schema  is  in  an 
infinite  loop.  But  the  program  schema  must  seek  and  test  all  2-*n 
terminal  nodes  and  then  halt.  Therefore  the  program  schema  needs  at 
least  2-»n  equivalence  classes. 

The  Single  Instance  Theorem: 

1  single  recursive  schematic  eguation  that  defines  a  function  form  f 
can  be  transformed  into  an  equivalent  program  schema  if  the  form  f 
appears  only  once  in  the  definition  ci  the  function. 
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Proof: 

Define  (F->d  x)  to  be  F  applied  n  tines  to  some  argument  x. 
(F-'O  x)  =  x 

(F-(nfl)  x)  =  (F  (F->n  x) ) 

For  example  {F->1  x)  is  (F  x)  and  (F-%2  x)  is  (F  (F  x) ) . 

Suppose  the  definition  of  f  is  of  the  fora 


(f  k)  =  if  {alpha  k} 

then  {beta  k} 

else  {qaoma  if  {delta  k} )  kj 


where  {alpha  k}  is  the  expression  that  is  evaluated  before  the 
recursive  call  to  f,  {  beta  k}  is  the  expression  that  is  evaluated  if 
there  is  no  recursive  call  to  f,  and  {gamma  (r  {delta  k} )  k}  is  the 
value  for  a  recursive  call  to  f.  The  reader  say  or  may  not  want  to 
exanin  the  following  tree  which  shows  f  partially  expanded: 


(if  {alpha  {aelta-»0  k} } 
then 

{beta  {delta->0  k}  J 
else 

{gamma 

(if  {alpha  {delta-il  k} } 
then 

{beta  {deita-il  k}} 
else 

(gam  a  a 

(if  {alpha  {delta-»2  k} } 
then 

{beta  {delta-2  kj} 
else 
. .  .) 

{delta-i  1  i  ,}) 


{delta-«0  k}}> 
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The  function  f  can  be  re-«ritten  as  follows: 


(f  k)  =  (block  ({a  <-  k)  n  i  j) 

;Mm,  n ,  i,  and  j  are  registers  of  the  program  schema  f;  ■  is 
initialized  to  the  value  of  k" 

(repeat  {) 

(if  {alpha  o’  then  (return)) 

(m  <-  {delta  a} ) ) 

(i  <-  k) 

(n  <-  {beta  m} ) 

(repeat  ((i  <~  k)  (n  <-  k) ) 

(if  {alpha  i] 
then 

(exit  f  n)) 

(i  <-  {delta  i}) 

(repeat  ( ( j  <-  i)  (a  <-  k) ) 

(if  {alpha  jj  then  (return)) 

(j  <-  {delta  j}) 

(a  <-  {delta  a] ) ) 

(n  <-  {gamaa  n  a} ) ) ) 

He  would  like  to  repeat  the  iterative  definition  of  f  giving  coaments. 
An  expression  that  appears  within  [  and  ]  is  an  intention  that  is 
expected  to  be  true  whenever  control  passes  through  the  expression. 

It  is  not  necessary  to  understand  the  intentions  in  o; uer  to 
understand  the  schema  f.  In  fact  many  readers  might  prefer  not  to  read 
the  intentions.  The  intention  functions  fa,  fc,  and  fd  are  intended 
to  express  what  goes  cr.  in  loops  a,  c,  and  d  respectively. 


(f  k)  =  (block  ((a  <-  k)  n  i  j) 

;"m,  n,  x,  and  j  are  registers  of  the  prograa  schema  f;  a  is 
initialized  to  the  value  of  k" 

(repeat  a  () 

(if  {alpha  a}  then  (exit  a)) 

(3  <-  {delta  a]  •  ) 

{define  'fa  a)  -  if  {alpha  a]  then  s  else  {delta  a)  ] 

[  (a  *  (fa  k))  ; "I t  is  our  intent  that  e  be  egual  to  (fa  k)  at 
this  point.  It  can  be  shown  by  induction  that  this  intention  is 
always  realized."! 

(i  <~  *) 

(n  <-  {beta  a] ) 


m&m 
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(repeat  c  ( (i.  <-  k)  {n  <-  k) ) 

(if  {alpha  i} 
then 

[  (f  k;  =  (fc  {delta  (fa  k)}  k)  =  n] 

(exit  f  n) ) 

[n  =  (f  i)  ] 

[define  (fd  n  a  j)  =  if  (alpha  j}  then  {gamma  n  a} 
else  (fd  n  {delta  n}  {delta  j} )  ] 

[define  (fc  n  i)  =  if  {alpha  i]  then  n  else  (fc  (fd  o 

k  i)  (delta  i) )  ] 

[n  =  (fd  {beta  (fa  k)}  k  i)  ] 

(i  <-  {delta  i} ) 

(repeat  d  ( ( j  <-  i)  (m  <-  k) ) 

(if  {alpha  j}  then  (exit  d ) ) 

(j  <-  {delta  j}) 

(a  <-  {delta  a}  )  ) 

(n  <-  {gaaaa  d  a}} 

[n  =  (f  »)  ])) 


8.  1.  1*  1.  2  Compilation 


Me  can  look  at  program  schemata  and  recursive  schemata  as 
automata  that  operate  cn  the  universe  of  terms  as  a  data  space.  A 
finite  state  schema  automaton  operates  under  a  finite  state  control 
structure  using  a  finite  number  of  registers  each  of  which  can  hold 
one  term.  As  a  primitive  operation  the  automaton  is  allowed  to  create 
a  term  by  applying  a  function  to  terns  stored  in  its  registers  and 
then  to  store  the  result  back  in  a  register.  In  addition  the 
automaton  is  allowed  a  finite  number  of  primitive  predicates  to  test 
the  contents  of  its  r  )gisters.  The  class  of  finite  state  schema 
automata  is  equivalent  to  the  class  of  program  schemata  in  the  obvious 
way.  Program  schemata  can  be  regarded  as  being  executed  by  a  finite 
state  schema  automaton  after  a  suitable  compilation.  A  pushdown 
schema  autonaton  is  defined  to  be  a  finite  stcte  schema  automaton  with 
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a  pushdown  stack.  Id  addition  a  pushdown  schema  automaton  is  allowed 
a  finite  number  of  distinguished  constants  as  terns  together  with 
predicates  that  test  for  the  distinguished  constants.  Be  will 
investigate  the  relationship  between  these  nachines  and  schenata.  The 
appropriate  kind  of  equivalence  is  one  in  which  side  effects  are 
allowed.  Two  scheHata  will  be  said  to  be  side-effect  equivalent  if 
they  are  the  sane  function  for  all  interpretations  including  those 
which  involve  side  effects.  An  unicterpreted  function  nay  change  the 
definition  of  aay  of  the  unintepreted  functions  as  a  side  effect  of 
being  evaluated.  For  exanple  the  schenata  jl  and  j2  below  are  not 
side-effect  equivalent. 


{ j  1  x)  =  if  (P  x)  then  x 

else  (jl  (pi  (G  x}  (G  x) ) ) 

(pi  x  y)  =  x 

(j2  x)  =  if  (P  x)  then  x 

else  ( j2  (G  x) ) 

The  free  interpretations  for  side  effect  schenata  are  the  ones  in 
which  each  uninterpreted  function  synhol  is  interpreted  ss  the 
function  which  evaluates  to  the  list  of  al1  the  primitive  terns  that 
have  been  previously  evaluated  in  the  computation.  For  exanple  the 
side-effect  protocol  tree  for  j2  is 


if  (P  x) 

then  (x  >  (P  x) } 
else 

if  (P  IG  2)) 

then  { (G  x)  ♦  '■ 
else 


"  (G  X)  -<P  X)) 
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x)  -(P  x)} 


if  (P  (G~>2  x) ) 

then  {  (G  -•  2  X)  +  (P  (G-*2  X))  (G-2  X)  -  {P  (G  x)  )  (G 


else. . . 


On  the  other  hand  the  side-effect  protocol  tree  of  jl  is: 

if  (J?  x) 

then  {x  ♦  (P  x) } 
else 

if  {?  (G  x)) 

then  {(G  X)  +  (P  (G  X))  (G  x)  (G  x)  -  <P  x}} 
else 

if  (P  (G-2  x)) 

then  {<Gi2  x)  +  {P  (G-.2  x) )  (G-2  x)  (G-*2  x)  -  (P  (G 

x})  (G  X)  (G  X)  -(P  X)} 

else. . . 


Thus  jl  and  j2  are  net  side-effect  equivalent. 


Theorem  Side-effect  equivalence  ir  decidable  for  program 
schemata. 

Proof:  The  proof  is  by  tree  expansion.  Two  program  schemata 

are  side  effect  equivalent  if  and  only  i.f  for  every  execution  path  of 
one  schema  there  is  an  execution  path  for  the  other  with  the 
uninterpreted  functions  called  in  exactly  the  same  order.  Given  a 
cycle  in  one  schema  it  is  decidable  whether  the  cycle  can  be  ecbedded 
in  the  other. 


Coujecture:  side-effect  equivalence  is  decidable  by  tree 
expansion  for  recursive  schevati. 

If  this  conjee*1  ire  is  correct  then  we  can  attach  a  post  processor  to  a 
compiler  w’  decides  whetner  or  no.t  th2  compiled  code  is  side-effect 
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egui valent  with  the  source  code. 

The  BSf  syntax  for  prograa  schema  automata  is  as  follows: 


prograa  ::=  <ccaaand> 
cosaand  : : =  <block>  | 

<repeat>  | 

<again>  | 

<exit>  | 

<push>  | 

<pop>  I 

<conditional>  1 
<i:unctica-cali> 

value  ::=  false  ]  identifier  |  <literal-string> 
values  : : =  <value>  |  <value>  <values> 
pop  ipop)  |  (pop  <identifier>) 

exit  (exit  <naie>  <values>)  J  (return  <values>) 

conditional  : : *  (iftrue  <coaaands>  else  <ccaaands>)  | 
(ifeapty  <ccaaands>  else  <coaaands>) 
again  : :  *  (again)  |  (again  <naae>) 
push  : :*  (push)  |  (push  <value>) 
block  (block  <hody>) 

repeat  (repeat  <body>) 

function-call 

(call 

<nuaber-of-args> 
<uninterpreted-function>)  J 

(call 

<  nua  b  er-  o  f- ar  gs  > 

< unin ter preted-f unction> 
(<identfiers>) 

<coaaanda>)  | 

(call  2  is) 

identifiers  : : *  |  <Identifier>  <identifiers> 
body  <naae>  <declaration>  <coaaands>  | 

<declaration>  <coaaands> 
declaration  : :  *  (declarers) 

declarers  )  (<identif ier>  valuer)  <declarers> 

There  are  a  few  non- obvious  constructs  in  the  above  syntax. 
The  expression  (pop  <identifier>)  reaoves  the  top  eleaent  froa  the 
stack  and  aakes  it  the  new  'aloe  of  the  identifier,  lrguaents  to 
function  are  passed  on  the  stack  and  the  results  are  returned  on  the 


stack 
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The  Coapilation  Theorea: 


Foe  every  recursive  scheaa  there  is  a  side-effect  equivalent  pushdown 
scheaa  autoaaten. 


Proof : 


ie  shall  show  how  to  coapile  the  scheaa  f  defined  below: 


If  *) 


(block  ((y  <-  (B  x))» 

;*y  is  a  new  local  which  is  initialized  to  (B  z) " 
(if  (P  *) 

then  (K  z  y) 

elseif  (and  y  (P  (f  x) ) ) 
then  (K  y  x) 
else  (G  (R  y  x)  y) ) ) 


The  coapiled  fern  is 

(f  x)  ~  (block  ( (y  false)) 

(push  x) 

(call  1  H) 

(pop  y) 

(push  x) 

(call  1  P) 

(if  true 

(pop) 

(push  x) 

(push  y) 

(call  2  K' 

(return  1) 

else 

(pop) 

(pash  y) 

(iftrue 

(pop) 

(pash  x) 
(call  1  £) 
(call  1  p) 
(iftcue 


(pop) 
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(push  y) 
(push  x) 
(call  2  k) 
(return  1) 

else 


(POP)) 

else 

(push  y) 

(push  x) 

(call  2  K) 
(push) 

(push  j) 

(call  2  G) 
(return  1} ) ) ) 


8.  1.1.  1.3  Schemata  with  Besets 


Tags  cau  be  thought  of  as  identifiers  which  are  bound  at  each 
activation  level.  By  passing  the  activation  as  a  parameter  the  level 
of  activation  can  be  immediately  reset  by  executing  a  transfer  of 
control  through  the  activation.  In  order  to  obtain  an  equivalent 
machine,  we  can  extend  the  instructions  of  the  push  down  scheaa 
autoaaton  by  allowing  then  tc  store  a  pointer  to  the  top  element  of 
the  stack  into  one  of  the  registers.  The  resulting  class  of  machines 
is  called  the  reset  push  down  schema  automata.  If  the  stack  is  ever 
popped  back  past  a  location  that  is  pointed  to  by  a  register  then  the 
autoaaton  halt3  with  an  error.  He  found  discussions  with  Bike 
Fischer  helpful  in  analyzing  schemata  with  resets. 

The  Beset  Theorem: 

The  class  of  reset  push  down  schema  automata  is  equivalent  to  the 
class  of  ordinary  push  down  scheaa  automata. 

He  shall  show  how  we  can  translate  a  reset  push  down  schema 
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into  an  equivalent  ordinary  push  down  schema.  An  ordinary  function 
call  {f  x//1  ...  x//n)  will  be  translated  into  (call  (f  x//1  ...  x//n) 
(y  y//l  •••  y//1)  body)  where  we  will  explain  the  body  below.  The 
idea  is  that  if  the  function  f  wants  to  execute  a  non  local  transfer 
of  ccntrol  through  argument  x//i  we  can  simulate  this  by  returning  the 
corresponding  y//i  as  "e:  t"  or  "again"  depending  cn  whether  the  block 
x//i  is  to  be  exited  or  reiterated  respectivey.  Then  the  procedure 
which  makes  the  call  tc  f  can  test  the  values  of  the  y//i  and  take  the 
appropriate  action  depending,  how  the  name  was  generated.  Consider  the 
following  example: 


(try  x)  =  (repeat  tl  () 

(if  (Q  x) 
then 

(x  <-  (F  x)) 
elseif  (P  x) 
then 

(x  <-  (harder  (F  x)  tl)) 

;"tbe  name  tl  is  an  identifier” 

(if  (not  x) 

then  (return  false) ) 
else  (return  false) ) ) 

(harder  xl  tag)  =  (repeat  () 

(if  (Q  xl) 
then 

(x  <-  (F  xl))  ;"set  the  global  x  to  (F  xl)  " 

(again  *-*q)  ;"reiteratc  the  repeat  loop  named  tag" 
elseif  (P  x.) 
then 

(xl  <-  (harder  (F  xl)  tag)) 

(if  (not  xl) 

then  (return  false)) 
else  (return  false) ) 

He  can  rewrite  try  and  harder  as  try*  and  harder*  respectively  so 


that  resets  are  eliminated 


INPUT 


er  m  which  the  nodes  ore 
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(try*  x)  =  (repeat  tl  {) 

(if  (Q  x) 
then 

(x  <-  (P  x))) 
elseif  (P  x} 
then 

(x  <-  (call  (harder*  (f  x)  tl)  (y  yl  y 2) 

(if 

(is  y2  "again") 

then 

(again  tl) 

elseif 

(is  y2  "exit") 

then 

(exit  tl) 
else  y) ) ) 

(if  (net  x) 

then  (return  false) ) 
else  (return  false))) 


(harder*  xl  tag)  =  (repeat  () 

(if  (Q  x‘) 
then 

(x  <~  (F  x  1) ) 

(exit  harder*  false  false  ‘’again") 

;!,reiterate  the  loop  named  tag" 
elseif  (P  xl) 
then 

(x  1  <-  (call 

(harder  (F  xl)  tag) 

(y  yl  y2) 

(if 

(is  y2  "exit") 

then 

(exit  harder*  false  false 

"exit") 

elseif 

(is  y2  "again") 

then 

(exit  harder*  false  false 

"again") 

else  y) ) ) 

(if  (cot  xl) 

then  (return  false)) 
else  (return  false))) 
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3.1.1.  1.4  Decompilation 

The  Decompilation  Theorem: 

For  every  push  down  schema  automaton  we  can  effectively  construct  a 
side-effect  equivalent  recursive  schema. 

Proof: 

The  only  difficult  constructs  to  translate  are  the  push  and 
pop  commands.  Me  shall  translate  {push  <value>)  as  (<function> 
<value>  tags  false)  where  <function>  is  a  unique  function  name 
distinct  from  all  others.  The  function  is  defined  to  be  have  two 
arguments  x  and  y  and  have  a  body  which  is  the  code  that  fcllcws  the 
push  command  which  is  being  translated.  The  command  (pop)  is 
translated  as  (GO  <tag>)  <tag>:  where  <tag>  is  a  unique  tag  distinct 
from  all  others.  whereas  {pop  <identif ier>)  is  translated  as 
{<identifier>  x)  {GO  <tag>)  <tag>:.  The  idea  is  that  there  must 

be  a  tag  for  every  instance  of  a  call  to  pop  so  that  control  can  get 
back  to  the  proper  place. 

Consider  the  following  push  down  schema  automaton: 

{f  y)  =  (block  {) 

(push) 

(call  1  g) 

(return  1) ) 

(g  Y)  -  (repeat  () 

(push) 

(call  1  P) 

(iftrue 

(pop) 

(push) 

(call  1  Q) 
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(iftrue 


(pop) 

(repeat 


else 


0 

(ifempty 

(terminate 

(pop) ) ) 


(pop) 

(pop) 

(if  eap*:7 

(terminate  false)) 

else 


else 


(call  1  F) 


(Fop) 

(push) 

(call  1  L))) 


«t")> 


The  schema  f  can  be  decompiled  as  follows: 


(f  x)  =  (block  outer  () 

(fO  x  false  false  false  false  "t") ) 


(fO 


x  nl  n2  n3  n4  n5  n6  ea 
(f  1  x  tl  1 2  1 3  1 4 
(x  <-  <P  x)) 

(if 


m 


=  (repeat 
6  false) 


0 


x 

then 


(go  nl) 
tl: 

(f 2  x  tl  1 2  t3  tu  t5  t6  false) 
(r  <~  (Q  x)) 

(if 

x 


then 

(go  n2) 

t2: 


(repeat 


13: 


else 


0 

(if 

empty 

then 

(exit  outer 

(go  n3) 

) 


n")) 


(go  n4) 
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£  a  ; 


;go 

tS; 

n5) 

(if 

eapty 

then 

(exit 

else 

outer  false) 

else 

(x  <- 

(R  x)))) 

(go 

t6: 

n6)) 

(f 3  x  tl  1 2  t3  t4  t5  t6  false} 
(x  <-  (L  x)}) 

(f  1  x  nl  n2  n3  n4  n5  n6  empty)  *  {block  () 

(if 

x 

then 

(go  nl) 

else 

(go  a2) ) ) 

(£2  x  nl  n2  n3  n4  n5  n6  empty)  =  (block  () 

(if 

x 

then 

(go  n3) 

else 

(go  n4) ) ) 

(£3  x  nl  n2  n3  n4  n5  n6  empty)  =  (block  () 

(x  <-  (1  x)) 

(fO  x  nl  n2  no  n4  n5  n6  empty)) 

8* 1.1. 1.5  Primitive  Recursive  Schemata 


Definition  a  recursive  schema  f  will  be  said  to  be  PBIfllTIVE 
RECURSIVE  in  the  the  uninterpreted  function  symbols  0  if  f  can  be 
defined  recursively  as  (f  x//1  ...  x//n)  =  phi[x//1  ...  x//n  ]  where 
each  instance  (f  t//1  ...  t//n)  of  a  call  to  £  within  phi[x//1  ... 
x//n  ]  has  t//1  of  the  form  (h  x//1)  where  h  is  ia  the  set  0  and  the 
only  other  functions  in  the  definition  are  either  uniaterpreted  or  are 
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then selves  primitive  recursive  in  U. 

For  exaaple  the  following  sehena  is  priaitive  recursive 


8}  . 


{f  x)  =  if  {P  x) 

then  (Q  x) 

else  (C  if.  (1  x))  (f  (R  x)  ) ) 

The  following  scheaa  is  not  priaitve  recursive  in  { S } : 

(ackerman  w  x  y)  = 

(if  (Z  x) 

then 

if  (Z  w) 

then  y 
elseif  (0  w) 

then  (ZERO) 
else  (ONE) 
elseif  (Z  w) 
then 

{? 

(ackerman  (ZF.B0)  (S  x  1)  y) 
(ONE)) 

(a  ’•ersau 

(S  w  1} 

(ackersan  w  (S  x  1)  y) 

Y)  ) 


in  {L 


else 
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8. 1.1.2  Schemata  with  Counters 


We  would  like  to  present  another  example  of  a  function  that 
can  be  computed  by  a  recursive  schema  but  not  by  any  program  schema. 
Define  (P^n  x)  as  in  the  proof  of  the  Single  Instance  Theorem.  Thus 
((F-»n*1)  x)  =  (F  (F-'n  x) ) .  Suppose  that  we  successively  compute  (F 
x) ,  (F  (F  x)),  etc.  As  we  successively  compute  the  quantity  (F-*i  x) 
for  some  integer  i  we  shall  keep  a  running  count  of  the  number  of 
times  that  (P  (F->j  x))  has  been  true  for  j  less  than  i,  minus  the 
number  of  times  that  (P  (F-»j  x) )  has  been  false  for  j  less  than  i.  If 
this  count  ever  goes  negative  then  we  shall  return  false  as  the  value 
of  the  function  (zero  x)  ,  otherwise  the  function  (zero  x)  will  run 
forever. 

The  Counting  Conjecture  for  Program  Schemata 

The  recursive  schema  ’zero*  defined  below  is  not  schematically 
equivalent  to  any  program  schema. 


(zero  x)  *  (repeat  a  J) 

(if  (P  x) 

then 


end 


(x  <-  (positive  (F  x) ) ) 
(if  x 

then 

(again  a)) 
else 

(return  false) 

else 

(return  false)) 


The  schema  ’zero'  usej  the  schema  'positive'  to  keep  track  of  the 
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count  by  the  depth  of  recursion  of  the  scheaa  ’positive*. 


(positive  x) 


end 


(repeat  a  () 

{if  (P  x) 
then 

(x  <■*  (positive  (F  x) ) ) 
(if  x 

then 

(again  a)) 
else 

(return  false) 

e  lse 

(return  (F  x) ) ) 


Using  the  technique  of  loop  eliainatiou  we  can  convert  the  above 
functions  into  purely  recursive  schemata.  We  shall  define  a  scheaa 
zerol  which  is  equivalent  to  zero  and  a  scheaa  positivel  which  is 
equivalent  to  positive. 


(zerol  x)  =  (if  (P  x) 
then 

(if  (positivel  (F  x) ) ) 
then 

(zerol  (positivel  (F  x))) 
else 

false) 

else 

false) 

(positivel  x)= 

(if  (P  s) 
then 

(Af  (positivel  (F  x)) 
ti  en 

(positivel  (positivel  (F  x))) 
else 

false) 

else 

(F  x)) 

The  protocol  tree  for  the  scueaa  z  'CO  is 
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{if  (P  (F-0  x)  ) 
then 

{it  (P  (F-»  1  x)) 
then 

{if  (P  (F-*2  x)) 
then 


else 

{if  {P  (F-3  x)) 
then 


else 

(if  {P  (f-*4  x) ) 
then 


else 

false) ) ) 

else 

{if  (P  (F-«2  x)) 
then 

(if  (P  (F-3  x)) 
then 
else 

(if  (P  (P-*4  x)) 
then 
else 

else 

false) ) 

else 

fa Ise) 

However  a  progras  schewa  can  solve  the  problem  if  we  give  it  a 


counter.  He  postulate  the  functions  "v",  and  zero?  which 

respectively  add,  subtract,  and  test  for  zero.  The  following  prograw 
schewa  is  schematically  equivalent  the  the  function  zero: 


(zero)  x)  =  (block  (n)  (return  (zero2  x) ) ) 

(zero2  x)  =  (repeat  () 

V  *  (P  x) 
then 

(x  <-  (F  x)) 

(a  <-  n  ♦  1) 

else 

{if  (zero?  n)  then  (return  falsa)) 
in  <-  n- 1) ) ) 


l 
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By  allowing  recursive  schemata  to  use  a  counter,  we  can  construct  a 
function  ’reczero’  that  is  not  equivalent  to  any  ordinary  recursive 
schema,  the  function  reczero  counts  the  number  of  nodes  along  the 
bottom  of  the  L-R  tree  that  have  the  property  P  minus  the  ones  that  do 
not  have  the  property  P.  The  function  returns  the  value  false  if  the 
count  ever  goes  negative.  Be  assume  that  arguments  are  evaluated  from 
left  to  right. 


The  Counting  Conjecture. for  Recursive  Schemata: 


The  schema  (with  counters}  reczero  defined  below  is  not  equivalent  to 
any  ordinary  recursive  schema. 


(reczero  x)  =  (block  (n)  (return  (reczerol  x) ) } 

(reczerol  x)  = 

(if  (BOTTOM?  x) 

then 

(if  IP  x) 
then 

(n  <-  n+1) 
true 
else 

(if  (zero?  n)  then  (return  false)} 

(n  <~  n-1) 
true) 

else 

(if  (net  (reczerol  (L  x)  ) )  then  (return  false)} 
(if  (not  (reczerol  (R  x)))  then  (return  false)) 
(return  true)) 


The  reason  that  reczero  is  not  equivalent  to  any  recursive  schema  is 
very  similar  to  the  reason  that  no  recursive  schesa  can  search  the 
branches  of  the  L-tt  tree  in  parallel.  If  a  recursive  schema  is 
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equivalent  to  reczero  then  it  is  constrained  to  search  the  tree  in 
essentially  the  sane  order  that  reczero  searches  the  tree.  Otherwise 
it  could  be  made  to  fall  into  an  infinite  loop  on  an  interpretation 
where  reczero  converges.  We  conjecture  that  constrained  in  this 
fashion  a  recursive  schema  has  only  a  finite  number  of  states  in  which 
to  try  to  keep  the  count.  The  recursive  schema  cannot  succeed  for. the 
same  reason  that  we  conjecture  that  no  program  schema  is  equivalent  to 
the  function  zero  defined  above. 

Conjecture:  the  following  function  is  not 
schematically  equivalent  to  any  purely  schematic  recursive  system  of 
equations.  Tie  function  even  is  supposed  to  test  whether  the  number 
of  bottom  nodes  of  a  L-fi  tree  that  are  true  for  the  predicate  p  is  the 
same  as  the  nucfcer  that  are  false  for  the  predicate  P.  The  schema 
'even*  differs  from  the  schema  ’reczero*  in  the  crucial  respect  that 
’even*  always  looks  at  all  the  bottom  nodes  before  it  comes  to  any 
conclusions.  Thus  a  recursive  schema  that  tries  to  imitate  the 
schema  even  has  a  lot  a^re  room  in  which  to  maneuver.  We  conjecture 
that  no  recursive  schema  can  have  enough  internal  states  to  be 
equivalent  to  the  function  even  defiued  below. 

(even  x)  =  (block  (n) 

(even!  x) 

(return  (zero?  n  ) ) ) 

(evenl  x)  = 

(if  (BOTTCH?  x) 
then 

(if  (P  x) 
then 

(n  <-  n*1) 
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x) 

else 

(n  <-  n-1) 

x) 

else 

(even  (L  xj) 

(even  (R  x})) 
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8.  1.1.3  Parallel  Schemata 


He  introduce  the  delimiters  "|("  and  ")  "  to  delimit  quantities 
that  are  to  be  computed  in  parallel.  ihenever  a  process  executes  an 
expression  like  | (x)  it  divides  into  two  processes,  one  process 
executes  x  and  the  other  attempts  to  continue  normal  execution.  For 
example  in  the  expression  l  (2*3)  *  (4*5)  ,  the  product  4*5  is  computed  in 
parallel  with  the  sum  2*3.  Thus  the  expression  "(block  |  (return  x) 
(return  y)  ) "  is  defined  to  be  the  value  of  x  or  y  depending  on  which 
evaluates  first  in  seme  particular  but  unspecified  parallel 
computation.  Processes  can  coordinate  thexr  actions  through  locks, 
hny  expression  x  can  be  locked  by  (lock  x)  provided  that  the 
expression  is  not  already  locked.  If  x  is  already  locked  then  any 
process  which  executes  (lock  x)  will  be  blocked  until  x  is  unlocked  by 
the  primitive  (unlock  x) .  However  a  process  can  execute  (locked?  x) 
which  will  return  true  is  x  is  locked  but  will  lock  x  if  it  is 
unlocked.  The  kind  of  call  delimited  by  "| ("  and  ")  "  can  be 
implemented  using  the  following  primitives: 

(create  f)  will  create  a  new  processwhich  will  begin  execution 
with  a  call  to  f  and  will  return  the  name  of  the  created  process  as 
the  value  of  the  function  create. 

(resume  (p  send-args)  f)  will  suspend  execution  of  the  process 
that  calls  resume  and  will  resume  execution  of  the  process  nased  p 
with  arguments  send-args.  If  the  process  p  is  already  running  then 
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the  process  which  called  resuume  will  he  blocked  until  p  becomes 
suspended.  If  the  process  which  called  resume  is  itself  ever  resumed 
tben  it  will  invoke  f  with  the  arguments  received. 

(fork  (p  send-args))  will  resume  exeuction  of  the  process  p 
with  arguments  send-args  and  in  parallel  return  the  name  of  the 
process  forked  as  the  value  of  the  function  fork. 

(interrupt  p  x)  will  interrupt  the  execution  of  the  process  p 
and  then  begin  execution  of  x  IN  THE  PECCESS  p. 

(step  p)  will  step  the  process  p  through  one  step. 

By  adding  the  above  primitives  we  obtain  the  class  of  Parallel 
Schemata.  It  is  our  thesis  that  the  class  of  Parallel  Schemata  is  in 
fact  UNIVERSAL  for  the  class  of  all  effective  schemata.  By  this  we 
mean  that  for  any  effective  schema  there  is  a  timing  side-effect 
equivalent  parallel  schema.  Two  automat  a  and  b  will  be  said,  to  be 
timing  side-effect  equivalent  If  for  every  computation  of  a  there  is  a 
side-effect  equivalent  computation  of  \  where  the  timings  of  the 
control  primitives  of  t  are  allowed  to  be  arbitrarily  adjusted  and 
vice-versa. 

He  define  the  following  function  using  parallel  processing: 

(f  x )  —  (if  (P  x) 

then  x 
else 

begin 

[  (return  (f  (L  x) ) ) 

(return  (f  (E  x) ) ) 

end) 
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The  above  function  is  determinate  ti.°.  halts  and  has  the  sane  value 
independent  of  the  relative  speed  ai.  which  the  sub-processes  run}  on 
infinite  binary  trees  in  which  the  predicate  P  is  true  cn  only  one 
node. 

The  Parallel  Evaluation  Theorem: 

The  function  £  defined  .is  net  equivalent  to  any  recursive  schema. 
Proof:  Suppose  a  set  of  recursive  equations  {f//C,  f// 1 ,  . ..,  f//n] 

is  schematically  equivalent  to  f  with  f/'/0  equivalent  to  f.  That  is 
for  all  interpretations  of  the  uninterpreted  function  symbols,  the 
schemata  f  and  £//0  are  the  same  function.  Suppose  that  we  start  up 
f//0  on  input  x  and  make  the  predicate  F  false  for  every  node  to  which 
it  is  applied  as  f//0  computes  along.  If  the  computation  converges 
then  f//0  does  not  lock  at  some  node  which  is  a  contradiction  of  the 
supposition  that  f//C  is  eguivalant  to  f.  Therefore  the  computation 
runs  forever  and  the  sequence  of  statements  through  which  the  control 
passes  is  ultimately  periodic.  Consider  the  sequence  of  arguments  to 
one  of  the  functions  {call  it  f//i  for  Mf  subscripted  by  iM)  as  the 
control  passes  through  one  cycle.  Suppose  that  f//i  is  a  function  of 
j  arguments:  a// 1, . . . , a// j .  The  arguments  with  which  £//i  will  be 
called  after  the  control  has  passed  through  one  cycle  are  terms 
definable  from  a//1 ,  .  .  .  ,a// j  .  Let  us  call  them  a//1-»1 ,  .  . .  ,a//j-»1 . 

The  situation  can  be  diagrammed  as  follows: 


(£//i  a//tr* #a// j) ;  the  beginning  of  the  cycle  in  the 
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control  structure 

{£// i  a//1-0#  . . .  #a// j-*1)  ;  He  pass  throuqh  the  saae  point  of 
the  cycle  ii  the  contrcl  structure 

If  none  of  a//1-«1,  .  . .  ,a//j->1)  is  the  saae  as  one  of  a// 1 , . . .  ,a//1 
then  we  are  done  since  the  arguments  of  the  recursive  equations  are 
tracing  j  paths  down  an  expontentially  growing  tree  which  nean«=  that 
some  node  is  not  looked  at.  xf  we  set  the  interpretation  so  that  P  is 
true  for  the  node  then  we  have  a  contradiction.  We  conclude  that  the 
fact  that  one  of  a//1-»1,  ...,a//j-*1  night  be  same  as  one  of 
a//1 . . ,a// j  is  a  nuisance.  Let  us  call  the  arguaents  to  f//i  after 
we  have  gone  through  the  cycle  k  times  a//1-»k,  . .  .a//j-»k-  Observe  that 
if  we  go  through  the  cycle  j!  tines  then  there  will  be  some  i  such 
that  i  is  less  than  j!  and  a//  1-*i, . . . » a//j-«i  has  the  property  that  it 
is  an  epicycle.  By  this  we  lean  that  some  a//q-«i  is  the  sane  as  oae 
of  a//1, , . . ,a//j  if  and  only  if  it  is  the  sane  as  a//q.  All  such  a//g 
do  net  contribute  t.o  the  nunber  of  nodes  examined  since  they  are 
repeats  of  nodes  previously  exanined  in  exactly  the  sane  way.  The 
situation  can  be  diagranned  as  follows: 


(f //i  a/ /1j. • • J 


(f//i  a//1-1, 
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(f//i  a//1-»k,  . . .  ,a//j-<k}  ;  the  beginning  of  the  epicycle  in 
the  control  structure 

♦ 

(f//i  a//1-»(2*k),  .  . .  #a//j->  (2*k)  )  ;  we  pass  through  the  saae 
point  in  the  epicycle 

Threrefore  we  can  ccaplet.e  our  proof  by  applying  tc  epicycles  the 
above  argument  that  we  used  for  cycles. 
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8.1. 1-4  Locative  Schemata 


The  Locative  Theorem: 

If  locations  of  identifiers  are  an  allowed  data  type,  then  the  control 
structure  of  recursive  schemata  can  compute  any  partial  recursive 
function . 

Proof: 

Let  (at  x)  denote  the  location  of  the  identifier  x. 

Furthermore  suppose  that  we  have  a  function  in  of  cne  argument  which 
will  return  the  contents  of  its  argument.  The  proof  will  be  phrased 
in  terms  of  pushdown  schema  machines.  He  can  define  a  counter  using  a 
register  as  fellows: 


(block  ((cl  false)) 

(initialize-counterl)  =(block  (  ( w  false)) 

(push  (at  w) ) 

(pop  cl)) 

(count-upl)  =  (bloc):  ( (y  false)) 

(push  cl) 

(pop  y) 

(push  (at  y) ) 

(pop  cl)) 

(count-downl)  =  (block  f) 

{push  cl) 

(call  1  in) 

(pop  cl)  ) 

(zero-testi)  =  (block  {) 

(push  cl) 

(call  1  in) 

(iftrue  (push  "t”})  else  (push  false)))) 
Marvin  Minsky  proved  that  two  counters  are  universal.  Q.S.D. 
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8.1. 1.5  Schemata  with  Selectors  and  Eeplaceaent 

Another  way  in  which  we  can  proceed  is  to  impose  data  types  on 
the  computing  domain.  Storage  off  the  stacfc  can  be  established  by 
pos'.  elating  a  constructor  c  and  selectors  si  and  s2  such  that  for  all 
r  and  y  in  the  computing  domain  we  ha ver 

(si  (c  X  y) )  -  x 
(s2  (c  x  y) )  »  y 

in  the  domain  of  interpretation.  Classically  we  would  postulate  that 
every  call  to  the  constructor  must  return  a  new  element  of  the 
computing  doaain. 


(c  x  y)  =  (block  (z) 

(z  <-  (si  f  ree-storage-list)  } 

(f ree-storage- list  <-  (s2  f ree-storage-list) ) 

;*‘free-storage-list  is  tree  in  c" 

(return  (CCNSTROCTOR  x  y  z) ) 

The  point  is  that  in  general  (c  x  y)  will  not  be  the  same  as  (c  x  y) 
because  of  use  of  assignment  on  the  free  varialbe  f ree-storage- 1 ist. 
Other  than  in  this  fairly  trivial  way,  schemata  do  not  add  any  power 
to  recursive  schemata. 
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8. 1.1.7  Schemata  with  Equality 

Schemata  with  equality  are  allowed  to  make  use  oL  a  special 
predicate  (=  x  y)  whose  interpretation  is  that  x  ana  y  are  the  same 
clement  of  the  domain  cf  interpretation.  Universal  domains  of 
interpretation  for  schemata  sun  equality  are  the  Herbrand  universe 
with  a  congruence  relation  theta  such  that: 

1:  theta  is  an  equivalence  relation 

2:  if  x/1  theta  y/1,  ....  and  x/n  theta  y/n  then  for  each 
unin terpreted  function  f  and  predicate  p: 

(f  x/1...  x/n)  theta  (f  y/1  ...  y/n)  and 
(p  x/1  ...  x/n)  if  an  only  if  {p  y/1  ...  y/n) 

In  other  words  the  elements  cf  the  domain  of  interpretation  are  the 

equivalence  classes  of  theta. 


t 


f.'waa 


n 


8.1. 1.6  Hierarchical  Backtrack  Schemata 
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PLANNEE  uses  a  aore  powerful  control  structure  than  that  of 
the  recursive  function  call.  A  BACKTRACK  CONTROL  STRUCTURE  is  used 
which  means  that  at  any  point  a  process  can  fail  which  will  cause  it 
to  back  up  to  some  previous  state  and  then  continue.  The  priaitive 
function  (FAIL)  will  generate  a  siapie  failure.  The  primitive 
function  (FAILPCIHT  try  lose)  will  evaluate  the  expression  try.  If 
the  evaluation  succeeds  then  the  value  of  the  function  FAI1P0INT  is 
the  value  of  try.  Otherwise  the  value  of  the  function  FAILPOXNT  is 
the  value  of  lcse.  For  exaaple  the  value  of 
i+ 

(failpcinfc  {x  <-  2)  {x  <-  3)) 

(if  x=2  then  (fail)  else  4)) 

is  7  since  x  first  gets  the  value  2  but  then  is  given  the  value  3  when 
a  failure  backs  up  tc  the  function  FAILPOINT* 

8. 1.1.8.  1  Comparison  with  Recursive  Schemata 

He  shall  give  an  exaaple  tc  show  that  backtrack  control 
structure  is  more  powerful  than  recursive  control  structure. 

Backtrack  Scheaata  Are  flore  powerful  than  Recursive  Scheaata 


h 


l 
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The  backtrack  schema  g  defined  below  is  net  equivalent  to  any 
recursive  schema.  What  the  schema  g  does  is  to  search  the  following 
tree  for  x  looking  for  a  node  on  which  P  is  true: 


(L-«1  x) 

(L-2  x) 

{L-3  x) 

(R-1  {i-*2  X)) 

(L-*4  X) 

(R-*1  (L-4  x)) 

(H-1  (L-»1  x)) 

(R-2  (L-1  X))) 

(R-O  X) 

(R-2  X) 

(S-3  x) 


We  have  shown  in  the  section  on  parallel  schemata  that  no  recursive 
schema  can  do  the  search- 


(g  x)  =  (h  (f  x)) 

(h  2)  =  (if  z 

t  ten 

"true" 

else 

(fail) ) 


(f  *)  = 

(fail? 

(P  x) 
(block 


(y) 

;"y  is  a  new  local*’ 

(y  <-  x) 

(k 

(£  (I  x)) 

(if  (P  y) 

then  true 
else  (y  <-  (R  y) 


false))))) 


The  reason  that  we  make  the  function  k  defined  below  into  a  separate 
function  is  so  that  BOTH  arguments  will  be  evaluated. 
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(k  s  t)  =  if  s 

then 

"true" 
else  t 

Proof:  The  proof  .is  similar  to  the  proof  of  the  parallel 
evaluation  theorem.  Suppose  a  set  of  recursive  equations  [f//0,  f//1, 
...#  f//n}  is  schematicaly  equivalent  to  f  with  f//0  equivalent  to  f. 
Suppose  that  we  start  up  i//0  cn  input  x  and  make  the  prdicate  p  true 
for  every  node  to  which  it  is  applied  as  f//0  computes  along.  If  the 
computation  convereges  then  f//0  does  not  lock  at  some  node  which  is  a 
contradiction  ci  the  supposition  that  f//0  is  equivalent  to  f. 
Therefore  the  computation  runs  forever  and  the  sequence  of  statements 
therough  which  the  control  passes  is  ultimately  periodic. 

8.1.  1.8.2  Comparison  with  Hultiprocess  Schemata 

The  method  by  which  multiprocess  schemata  can  simulate 
hierachical  backtrack  schemata  is  messy  but  straight  forward. 

Hultiprocess  schemata  are  more  powerful  than  backtrack 
schemata.  One  example  which  may  show  this  is  the  one  used  to  show 
'hat  parallel  schemata  are  more  powerful  than  recursive  schemata. 
Unfortunately  we  have  not  yet  been  able  to  prove  that  backtrack 
schemata  cannot  search  the  full  L-D  tree.  So  we  sLall  resort  to  brute 
for.-e  techniques. 

He  would  like  to  define  the  P-leagth  of  an  expression  x  as  the 
number  of  times  which  D  can  be  applied  to  x  before  (P  x)  is  true. 


PROGRAM  SCHEMATA 


k  REGISTERS  EACH  OF  WHICH  CAN  HOLD 
AN  INTEGER  UP  TO  n 


J 


9/. 

/  u 


CL 
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Thus  (P- length  x)  =  (if  (P  x)  then  0  else  1+ (P-length  (D  x) ) )  Now  we 
would  like  to  define  a  schema  expt  such  that 

(expt  x  y)  =  (I-<  (2->  (P-length  x)}  y) 

Suppose  that  (P-length  x)  -  2.  Then  (expt  z  y)  -  (l->  {2-«2 )  y)  =  (I->4 
y)  =  (I  (I  (I  (I  y))J). 

(expt  x  y)  =  (if  (P  x) 
then 

(I  Y) 

else 

(expt  (D  x)  y  (expt  (D  x)  y) ) ) 

Now  we  claim  that  there  is  no  program  schexa  which  is 
equivalent  to  expt.  Suppose  to  the  contrary  that  there  is  a  program 
schema  with  k  registers  and  s  statements  which  is  equivalent  tc  expt. 
Such  a  program  schema  has  at  most  only  s  *  k-*  (P-length  x)  equivalence 
classes  of  states.  Thus  if  it  runs  for  more  than  s  *  k-* (P-length  x) 
steps  it  must  be  in  a  loop.  Therefore  it  cannot  possibly  produce  the 
output  (I-»  (2-’  (P- length  x})  y)  since  s  *  k-«(p-length  x)  is  less  than 
2-»(P-length  x)  for  large  values  of  (P-length  x)  .  This  is  a 
contradict  ion. 

In  an  exactly  analogous  fashion  we  can  prove  that  there  is  no 
recursive  schema  expt2  such  that 

(expt2  x  y)  =  (I-<  (2-»  (2-» (p-length  x) ) )  y) 

Suppose  that  there  is  a  recursive  schema  with  k  registers  and  s 
statements  which  is  equivalent  to  expt2.  Such  a  recursive  schema  has 
at  nest  only 


RECURSIVE  SCHEMATA 


STACK  OF  REGISTERS 


_  k  REGISTERS 

R]  R  2  R 

q  □  q;;.t 

i  I 
I  i 
I  I 


EACH  REGISTER  CAN  HOLD  AN 
INTEGER  UP  70  n. 
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3  =  s  *  {P-length  x) -<k  *  (P-length  x)-«(s  *  (P-length  x) -k) 
equivalence  classes  cf  states.  The  same  state  counting  argument  shows 
the  contradict  ion .  The  above  argument  has  been  independently 
discovered  by  Robin  Kilner. 

Theorem:  Multiprocess  schemata  are  more  powerful  than  backtrack 

schemata 

Proof:  He  will  apply  cur  brute  force  technique.  There  is  no 

backtrack  schema  expt3  such  tnat 

(expt3  x  y )  —  (I-»  (2-  (2-^  { 2-  (P-length  x)  ) ) )  y) 

Suppose  that  ttere  is  a  backtrack  schema  with  k  re-gisters  and  s 
statements  which  is  equivalent  to  expt3.  ~et  J  be  as  defined  above. 
The  recursive  schema  has  at  most  J-»J  equivalence  classes  of  states. 
Thus  if  it  runs  for  more  than  J-'j  steps  it  must  be  in  a  loop. 

Therefore  it  cannot  possibly  produce  tie  output  (I->  ( 2 -^2 -•2-'  (P- length 
x) )  y)  since  J->J  is  less  than  2->2->2->  (P-length  x)  for  1  arge  values  of 
{P-ler.gth  x)  .  This  is  d  contradiction. 


BACKTRACK  SCHEMATA 

STACK  OF  REGISTERS 


k  REGISTERS 

R1  R  2  R  k 


I 

I 

I 


EACH  REGISTER  CAN  HOLD  AN 
INTEGER  UP  TO  n 


HAS  AT  MOST  JJ  STATES  WHERE 
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8.2.  Synthetic  Theory 


8.2.1  Realizations 

8.2. 1.1  Realizations  fcr  the  Quantif icational  Calculus 

He  would  like  to  show  how  we  can  use  schemata  to  express 
procedurally  the  neaning  of  certain  constructive  logically  valid 
sentences  in  the  predicate  calculus.  Classically,  intuitionistic 
logic  has  been  used  to  prove  constructive  sentences.  However,  the 
connection  between  this  language  and  push  down  schema  automata  is 
somewhat  indirect.  He  need  to  define  the  notion  of  a  schema  g 
realizing  a  formula  phi.  Roughly  speaking  g  realizes  phi  if  it  tells 
how  to  compute  the  value  of  phi  from  the  subformulas  of  phi  depending 
on  the  logical  connectives  of  phi.  Kleene's  notion  of  "g  realizes 
phi"  is  defined  by  induction  on  the  structure  of  phi: 

For  {terms} .  g  realizes  phi  where  phi  is  a  term  if  g  is  true 
if  ana  only  if  phi  is  true.  For  example  (P  (F  w)  z)  realizes  (P  (F  w) 
z)  . 

For  {and...},  g  realizes  phi  =  (and  theta  psi)  if  (g  0) 
realizes  theta  and  (g  1)  realizes  psi.  Rote  that  g  really  is  two 
functions  in  disguise. 

For  {or...},  g  realizes  phi  =  (or  tbeta  psi)  if  whenever  (g  0) 
is  false  then  (g  1)  realizes  psi  and  whenever  (g  0)  is  not  false  tbeB 
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(g  1)  realizes  theta. 

For  {implies...}.  g  realizes  phi  =  (implies  theta  psi)  if 
whenever  h  realizes  theta  then  (g  h)  realizes  psi. 

For  (not..,],  g  realizes  phi  -  (not  theta)  if  for  no  h  is  it 
the  case  that  (g  h)  realizes  theta. 

For  {all...},  g  realizes  phi  =  (all  x  [theta  x])  if  for  all  x 
it  is  the  case  that  (g  x)  realizes  [theta  x). 

For  {some...},  g  realizes  phi  =  (some  x  [theta  x  ])  if  (g  1) 
realizes  [theta  (g  0)  ]. 


Consider  the  following  formula  which  we  shall  call  phi: 


(implies 

(some  x 

(implies  (A  z) 
(implies  (all  x  (Ax)) 


(B  »>>) 

;some  x  (B  x)  )  ) ) 


He  claim  the  function  g  defined  below  realizes  phi. 

g  =  (lambda  h  (lambda  A  (lambda  s 
(if  s  =  0 

tlen  (h  0) 

else  ((h  1)  (k  (h  0))))))) 

Suppose  that  h  realizes  (some  x  (implies  (A  x)  (B  x) ) ) 
(h  1)  realizes  (implies  (A  (h  0))  (6  (h  0))) 

suppose  that  k  realizes  (all  x  (Ax)) 

(A  (b  C) )  realizes  (A  (h  0)) 

( (h  1)  (k  (h  0)))  realizes  (B  (h  0)) 

(((g  h)  k)  1)  realizes  (B  ( ( (g  h)  k)  0)) 

( (g  b)  k)  realizes  (some  x  (B  x) ) 

(g  h)  realizes  (implies  (all  x  (Ax))  (some  x  (B  x))) 
g  realizes  pbi 


8.2.1  page  381 


He  are  interested  in  knowing  when  a  formula  can  be  realized 
constructively . 

Realization  Theorem  for  Recursive  Schemata  with  Functional  Arguments. 

If  phi  is  prcveable  in  intui tio nistic  logic,  then  phi  is 
realizable  by  a  recursive  schema  with  functional  arguments.  The 
Realization  Theorem  represents  one  approach  toward  a  constructive 
theory  of  computation.  Prom  a  description  of  the  kind  of  object  that 
we  would  like  to  have  given  the  description  of  certain  other  objects 
as  input,  we  derive  a  program  for  computing  our  goal.  Actually  we 
shall  prove  that  for  intuitionistic  logic  the  realization  function  can 
be  made  primitive  recursive.  The  proof  is  a  slight  modification  of 
the  standard  proof  for  the  integers.  It  is  a  warm  up  for  the 
analogous  proof  for  the  deductive  system  of  PLANNEE.  However,  in 
PLANNER  we  reguite  the  full  power  of  the  recursive  functions  for  our 
constructive  realizations. 

Proof:  The  following  proof  is  by  induction  on  the  structure  of 
intuitionistic  proofs  using  natural  deduction.  It  goes  by 
straightforwardly  winding  and  unwinding  of  definitions.  With  a  little 
work  we  could  get  PLANNEE  to  create  the  proof. 

{and  introduction} 

theta  realized  by  say  g 
psi  realized  by  say  h 

(and  theta  psi)  realized  by  (lambda  s  (if  (s  =  0)  then  g  else 
h) ) 
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{and  eliminaticc} 

(and  theta  psi)  realized  by  say  g 


theta  realized  by  (g  0) 
psi  realized  by  (g  1) 


{or 


9)  ) 
9)  ) 


in  tro] 

psi  realized  by  say  g 
(or  theta  psi)  realized  by 
(or  psi  theta)  realized  by 


(lambda  t  (if  t-0  then  false  else 
(lambda  t  (if  t=0  then  true  else 


{or  elim} 

(or  theca  psi)  realized  by  say  g 

theta  hypothesis;  suppose  that  theta  is  realized  by  h 


eventually  deduce  say  cmega  which  is  realized  by  (m  h) 
for  some  recursive  m  using  the  inductive  hypothesis 

psi  hypothesis;  suppose  the  psi  is  realize,,  by  k 


eventually  deduce  omega  which  is  realized  by  (1  k)  for 
some  recursive  1  using  the  inductive  hypothesis 


cmega  which  is  realized  by  (if  (g  0)  then  (a  (g  1))  else  (1  (g 

1))) 

{implies  intro} 

omega  hypothesis;  suppose  omega  is  realized  by  h 


eventually  deduce  say  psi  which  is  realized  by  (q  h) 
for  some  recursive  g  using  the  inductive  hypothesis. 


(implies  oaega  psi)  realized  by  (lambda  b  (g  h)  ) 
(implies  elii} 

(iaplres  oaega  psi)  realized  by  say  g 
oaega  realized  by  say  h 


psi  realised  by  (g  h) 
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(neg  intro} 

omega  hypothesis?  suppose  that  omega  is  realized  by  h 


eventually  deduce  say  (not  psi)  which  is  realized  by 
(g  h)  for  some  recursive  g  using  the  induu;_ive  hypothesis 

eventually  deduce  psi  which  is  realized  by  (k  h)  tor 
some  recursive  k  using  the  inductive  hypothesis. 


(not  omega)  which  is  realized  by  any  function  since  it  is 
impossible  for  both  (net  psi)  to  be  realized  by  (g  h)  and  for  psi  to 
be  realized  by  (k  h)  . 

(all  intro} 

x| 

i 

1 


1 

! eventually  deduce  say  [omega  x]  which  is  realized  by 
(g  x)  for  some  recursive  g  using  the  inductive  hypothesis 


(all  x  [omega  x  J)  realized  by  (lambda  x  (g  x)  ) 
[all  elim} 

(all  x  [omega  x  ])  realized  by  say  g 


[omega  t]  for  some  term  t;  realized  by  (g  t) 
(exist  intro} 

[omega  t  ]  is  realized  by  say  g  where  t  is  a  term 


(exist  x  [omega  x }}  is  realized  by  (lambda  s  (if  (s  =  0)  then 
t  else  g) ) 

[exist  elim} 

(some  x  [omega  x  ])  realized  by  say  g 
x|[omega  x]  realized  by  (g  1) 

I 

I 


I 

(eventually  deduce  say  psy  which  does  not  contain  x 
free;  psy  is  realized  by  (a  (g  0)  (g  1))  for  some  recursive  m  using 
the  inductive  hypothesis. 
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psy 

Thus  ye  have  ccrpieted  the  inductive  proof. 


Intuitionist  ic  lap le pent;* tic n  Theorem 

For  every  recursive  schema  P,  we  can  effectively  find  a  first 
order  formula  [theta  x  y]  such  that  P  is  total  if  and  only  if  {all  x 
(some  y  [theta  x  y  ])  )  is  proveabie  in  intuitionistic  logic. 
Furthermore,  the  program  P  on  input  x  converges  to  the  value  y  if  and 
only  if  [theta  x  y]  is  proveabie  in  intuitionistic  logic.  We  assume 
that  all  uninterpreted  function  symbols  in  schemata  are  total. 

We  shall  give  an  example  of  hew  to  construct  tho  formula  theta 
for  the  following  program  which  is  due  to  Paterson: 


(9  x) 


{if 


(T  (F  x[ } 
then  (h  x  (F  x)  ) 
else  x) 


(h  x  y )  = 


(i  * 


(1  (F  (F  y)J) 


then  x 

elseif  (I  {F  x)) 

then  (h  (F  x)  (F  |F  y))) 
else  (g  (F  x* )  ) 

We  can  obtain  the  formula  that  we  require  by  doing  a  straight  forward 
translation  of  the  recursive  eguations  into  the  guantif icational 
calculus.  These  formulas  are  similar  in  intent  to  those  of  Wanna, 
however  we  need  use  only  intuitionistic  logic  to  obtain  the  result  we 
require.  The  formula  [theta  x  y]  to  be  constructed  is  the 


conjunction  of  the  following  three  formulas  where  t*iffw  is  an 
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abbreviation  for  "if  and  only  if": 


(iff 

(PG  x  y) 

(or 

(end  (1  (F  x) }  (PH  x  (F  x)  y)  ) 
(and  (not  (T  (U  x)  )  (y  =  x) ) ) )  ) 

(all  xl  x2  y  (iff 

(PH  xl  .x2  y) 

(or 

(and  (1  (F  (F  x2) )  }  (y  =  xl)) 

(and 

(not  (T  (F  (F  x 2 )  )  )  ) 

(T  (F  xl)) 

(PH  (F  xl)  {?  (F  x2)  )  y)) 

(and 

(not  (1  (F  (F  x2)  )  }  ) 

(not  (T  (F  xl) ) ) 

(PG  (F  xl)  y) )  ) )  ) 


(all  x  (or  (T  x)  (not  (T  Xf)))  '  ~ 

The  last  statement  comes  from  the  fact  that  we  are  assuming  that  all 
uninterpreted  functions  are  total.  The  schema  g  is  indeed  total. 

Even  after  adding  selectors  and  constructors  the  realization 
theorem  can  still  be  proved  in  the  standard  way.  He  introduce  the 
predicate  atom  which  tests  to  see  if  its  argument,  is  atomic  and  thus 
cannot  be  broken  down  using  the  selectors.  The  following  rule  is 
added  to  intuitionistic  logic: 


(al3  x  (implies  (atom  x)  [theta  x})}  realized  by  say  g 
x#yi[theta  x]  hypothesis;  suppose  [theta  x]  is 
realized  by  (a  x) 

|[theta  y]  hypothesis;  [theta  y  ]  is  realized  by  (a 


y) 


1 
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leventually  deduce  [theta  (c  x  y)  ]  realized  by  say 
(h  m  x  y)  using  the  inductive  hypothesis 

(all  x  [^heta  x]/  realized  by 
(k  x)  =  (if  (atom  x) 

then  (g  x) 

else  (h  k  (si  z)  (s2  z)  ) } 

Sometimes  an  increase  in  efficiency  can  be  obtained  from 
replacement  operators  rl  and  r2  such  that 


if  x 

- 

(si 

z)  and  y  =  (s2 

2) 

then 

after 

(rl  z 

w) 

we  have 

'si 

z)  =  v,  and 

(s2 

2) 

=  y 

if  x 

= 

(Si 

z)  and  y  =  (s2 

2) 

then 

after 

(r 2  z 

v) 

we  have 

(si 

z)  ~  x,  and 

(s  2 

Z) 

-  w . 

He  shall  call  schemata  that  allow  the  use  of  selectors  and  replacement 
operators  list  structure  schemata.  Two  schemata  will  said  to  be 
equivalent  as  list  structure  schemata  if  for  all  interpretatic ns  of 
the  uninterpreted  function  symbols  they  are  the  same  function.  For 
schemata  that  dc  not  explicitly  contain  si,  s2 ,  rl,  or  r2  list 
structure  equivalence  is  the  same  as  side-effect  equivalence.  We  have 
shown  above  how  to  construct  a  universe  of  terms  so  that  two  schemata 
are  side-effect  equivalent  iff  they  are  equivalent  over  the  domain  of 
terms.  It  is  impossible  to  use  the  universe  of  terms  as  a  universal 
domain  of  interpretation  when  the  use  of  replacement  operators  is 


allowed. 
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8.3.  Current  Problems  and  Future  Work 


How  can  we  characterize  more  precisely  the  difference  between 
functions  that  need  to  use  a  recursive  or  parallel  control  structure 
as  opposed  to  these  that  only  need  a  simple  iterative  proqram 
structure?  Tte  problem  of  deciding  whether  any  given  recursive 
schema  can  be  rewritten  as  a  program  schema  .is  of  course  undecidaDle. 
He  would  like  to  find  general  criteria  of  independent  interest  which 
would  be  sufficient  to  guarantee  that  a  recursive  schema  could  not  be 
rewritten  as  a  program  schema. 

There  is  general  agreement  that  the  theory  of  computation  is 
currently  not  in  good  Shape;  The  three  major  areas  (automata  theory, 
recursive  function  theory,  and  special  case  hacks)  are  not  applicable 
to  practical  programs.  He  can  contrast  our  plight  with  the  situation 
in  applied  physics.  An  applied  physicist  finds  that  it  is  essential 
to  understand  fundamental  physical  laws  both  in  designing  his 
experiments  and  in  interpreting  their  results.  No  such  fundamental 
laws  and  principles  are  known  in  programing.  Recursive  function 
theory  sets  the  very  outer  limits  of  what  is  possible.  Few  theories 
are  more  elegant.  However,  the  fact  that  classical  recursive  function 
theory  deals  with  the  indices  of  the  partial  recursive  functions  and 
not  with  th<;  meaning  of  the  programs  has  been  a  fundamental 
limitiation  on  the  applicability  of  the  theory.  For  example  the 
recursion  theorem  says  that  fixed  points  exist  for  any  acceptable 


Goedel  nu&ber’Dg.  Almost  all  the  classical  theorens  of  recursive 
function  theory  can  be  derived  using  only  the  Godel  axioms  for  indices 
of  partial  recursive  functions*  Similarly,  the  conplexity  theory  of 
the  recursive  functions  can  be  derived  froB  81ub>*s  axioms  for  indices. 
Automata  theorists  have  been  able  to  discover  some  of  the  structure  of 
various  liaited  classes  of  automata  such  as  finite  state  machines, 
push  down  machines,  and  space  and  time  bounded  machines.  However, 
since  the  theory  developed  has  been  mostly  concerned  with  closure  and 
complexity  properties  of  the  special  machines  considered  as  acceptors, 
it  has  had  limited  applicability  to  real  computer  programs.  Host 
programs  are  not  structured  in  the  way  required  to  fall  into  one  of 
the  special  classes  of  machines.  Some  theorists  hope  that  by  studying 
enough  examples  of  very  narrow  domains  of  algorithms  where  we  have  a 
lot  of  domain  dependent  knowledge  that  we  can  induct  a  theory  of 
computation  in  a  Baconian  fashion.  Deep  studies  have  been  made  on 
guestions  such  as  how  fast  integers  can  be  aultipliea  aud  how  fast 
matrices  can  be  multiplied.  Studies  in  the  theory  of  searching  and 
sorting  appear  tc  be  more  r.  levant  for  constructing  a  unified  theory 
of  computation  since  they  are  concerned  with  basic  computational 
abilities. 

Studying  the  properties  of  programs  schematically  offers 
several  advantages.  Schemata  can  be  programmed  in  a  realistic 
fashion.  they  mirror  the  structure  of  programs  that  are  used  in 
applications.  Using  them  we  can  precisely  define  structural 
properties.  Properties  of  the  structural  classes  can  be 
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demonstrated.  Schemata  give  us  a  tool  by  which  we  can  rigorously 
formulate  and  prove  statements  that  every  programmer  intuitively 
knows.  We  have  used  schemata  to  make  a  kind  of  distinction  between 
semantic  and  syntactic  extensions  to  programming  languages.  The 
intent  of  the  restriction  that  functions  be  uninterpreted  is  to  try  to 
prevent  our  mathematics  frca  falling  into  what  Perlis  likes  to  call 
the  '’Turing  Machine  Tar  Pit,”  By  using  uninterpretod  function  symbols 
we  can  prove  both  analytic  and  constructive  theorems  about  classes  of 
programs.  In  the  analytic  theory  the  mathematical  properties  of  the 
structural  classes  is  expounded.  In  the  constructive  theory  the 
process  by  which  schemata  can  be  constructed  from  goal  oriented 
language  such  as  PLANNER.  The  intention  is  only  partially  realized 
and  we  must  search  for  ether  natural  mathematical  structures  to  impose 
on  our  schemata  in  order  to  obtain  a  mere  realistic  theory  of  semantic 
extensions  to  programming  languages.  we  are  continuing  to  investigate 
what  gains  in  efficiency  can  be  obtained  from  the  following  extensions 
to  programming  languages; 
recursion 

tacktracK  control  structure 
PLANNER  primitives 
Locations  as  a  type 
resets 

free  identifiers 
parallel  evaluation 

replacement  operators  for  constructors. 
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10.  Index  of  Procedures 


The  type  hierarchy  is  given  at  the  beginning  of  chapter  4. 
The  syntax  primitives  are  given  after  the  function  BEAD.  The  page 
number  gives  the  explanation  of  the  procedure. 
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166 

TTPE-YECTOB 

85 

UBASSIGN 


172 
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UNEX1END 

USFALSE 

UNIQUE 

UNIQUELY? 

UNIQUIZE 

UNLOCK 

UNBONITOR 

UNPRCTECT 

UNSET-ALARH 

UNSET-TIMER 

UNSBARE 

UPDATE 

UPPER 

VALUE 

VARIABLES 

VECTOR  1-CONSTRUCTOR 
VECTOR  ’-DECOBECSEH 
VEL 

WAIT-CALL 
WAIT- 'JET 
WES  E 


86 

91 

230 

141 

140 

170 

166 

163 

90 

90 

144 
226 
154 
151 
239 

145 
185 
177 
126 
132 
179 
105 


